Principles Of Secure Processor Architecture Design
Principles of Secure ProcessorArchitecture DesignSlides and information available /Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)1
Principles of Secure ProcessorArchitecture DesignJakub SzeferAssistant ProfessorDept. of Electrical EngineeringYale UniversityASPLOS 2019 – April 14th, 2019Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)2
Tutorial Outline8:30 – 9:009:00 – 9:309:30 – 9:459:45 – 10:0010:00 – 10:2010:20 – 10:3010:30 – 10:4510:45 – 11:3011:30 – 12:0012:00Secure Processor ArchitecturesTrusted Execution EnvironmentsBreakHardware Roots of TrustMemory ProtectionMultiprocessor and Many-core ProtectionsBreakSide-Channels Threats and Protections& Speculative or Transient Execution ThreatsPrinciples of Secure Processor Architecture DesignEndTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)3
The BookJakub Szefer, ”Principles of Secure ProcessorArchitecture Design,” in Synthesis Lectures onComputer Architecture, Morgan & ClaypoolPublishers, October 2018.http://caslab.csl.yale.edu/books/Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)4
Secure Processor ArchitecturesTrusted Execution EnvironmentsHardware Roots of TrustMemory ProtectionMultiprocessor and Many-core ProtectionsSide-Channels Threats and ProtectionsSpeculative or Transient Execution ThreatsPrinciples ofSecure Processor Architecture DesignTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)5
Types of Security Related ArchitecturesSecure ProcessorArchitectureSecure Co-Processoror HSM ArchitectureProcessor ChipProcessor ChipCore Core Co-Processor Chip SecurityCrypto UncoreuProcSec. I/OCrypto PUFs CryptographicAcceleratorsProcessor ChipSecurityMonitorProcessor ChipAcceleratorNetwork CardMonitorCryptoCryptoCryptoTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)I/O, Mem.,or Dev.6
Brief History of Secure Processor ArchitecturesStarting in late 1990s or early 2000s, academics have shown increased interest in secure processorarchitectures:XOM (2000), AEGIS (2003), Secret-Protecting (2005), Bastion (2010),NoHype (2010), HyperWall (2012), CHERI (2014), Sanctum (2016),Keystone (about 2017), MI6 (2018)Commercial processor architectures have also included security features:LPAR in IBM mainframes (1970s), Security Processor Vault in Cell Broadband Engine (2000s),ARM TrustZone (2000s), Intel TXT & TPM module (2000s), Intel SGX (mid 2010s),AMD SEV (late 2010s)Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)7
Baseline (Unsecure) Processor ArchitectureA simplified view of a processor and the software stack in a general-purpose computer:AppAppAppGuestOSAppAppAppAppAppAppGuestOS Hypervisor (VMM)HardwareGuestOSProcessor ChipCore Core UncoreMemoryTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)I/O Devices8
Baseline (Unsecure) Processor HardwareTypical computer system with no secure components nor secure processorarchitectures considers all the components as trusted:Processor ChipCore Core Information can be extractedfrom memory or memorycontents can be modified. Snooping on the systembus is possible to extractinformation.UncoreMemoryI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Compromised or maliciousdevices can attack othercomponents of the system.9
Baseline (Unsecure) Processor SoftwareTypical computer system uses ring-based protection scheme, which gives most privileges(and most trust) to the lowest levels of the system software:Ring 3AppAppAppAppAppAppRing 0GuestOSGuestOSRing -1AppAppApp GuestOSHypervisor (VMM)Compromised or maliciousOS can attack all theapplications in the system.Compromised or maliciousHypervisor can attack allthe OSes in the /wiki/File:Priv rings.svgTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)10
New Privilege LevelsModern computer systems define protections in terms of privilege level or protection rings,new privilege levels are defined to provide added protections.Ring 3Application code, least privileged.Rings 2 and 1 Device drivers and other semi-privilegedcode, although rarely used.Ring 0Operating system kernel.Ring -1Hypervisor or virtual machine monitor (VMM),most privileged mode that a typical systemadministrator has access to.Ring -2System management mode (SMM),typically locked down by processor manufacturerRing -3Platform management engine, retroactively named “ring -3”,actually runs on a separate management /File:Priv rings.svgTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)19
Extend Linear Trust with New Protection LevelsThe hardware is most privileged as it is the lowest level in the system. There is a linear relationship betweenprotection ring and privilege (lower ringis more privileged) Each component trusts all the software“below” itRing 3AppAppAppAppAppAppRing 0GuestOSGuestOSAppAppApp Ring -1Hypervisor (VMM)Ring -2SMMRing -3SecESecurity Engine (SecE)can be something likeIntel’s ME or AMD’s PSP.Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)GuestOSHardware20
Add Horizontal Privilege SeparationNew privileges can be made orthogonal to existing protection rings.NormalOperation E.g. ARM’s TrustZone’s “normal” and “secure” worldsPrivilegedOperation Need privilege level (ring number)and normal / secure privilegeSecurity levels from a lattice:Ring -1PrivilegedRing -1NormalRing 0NormalRing 0PrivilegedRing 3PrivilegedRing 3NormalTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS :Priv rings.svg21
Breaking Linear Hierarchy of Protection RingsExamples of architectures that do and don’t have a linear relationship betweenprivileges and protection ring level:Ring 3AppAppAppRing 3AppAppTSMAppRing 3AppAppEnclAppaveRing 0GuestOSRing 0GuestOSRing -1HVRing -1Ring -2SMMRing -3SecEHardwareNormal ComputerRing 3AppAppAppRing 0GuestOSRing 0GuestOSHVRing -1HVRing -1HVRing -2SMMRing -2SMMRing -2SMMRing -3SecERing -3SecERing -3SecEHardwareHardwareHardwareE.g. BastionE.g. SGXE.g. SEVTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)22
Example Secure Architecture: Intel SGXSimplified schematic of Intel SGX architecture and the protected GuestOS Hypervisor (VMM)GuestOSProcessor ChipCore Core MEUncoreSMMMEHardwareMemoryI/O DevicesEmoji Image:https://www.emojione.com/emoji/1f479Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)23
Example Secure Architecture: AMD SEVSimplified schematic of AMD SEV architecture and the protected Virtual Machines.AppAppAppGuestOSAppAppAppAppAppAppGuestOS Hypervisor (VMM)GuestOSProcessor ChipCore Core PSPUncoreSMMPSPHardwareMemoryI/O DevicesEmoji Image:https://www.emojione.com/emoji/1f479Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)24
Example Secure Architecture: ARM TrustZoneSimplified schematic of ARM TrustZone architecture and the normal and protected orldOSOSProcessor ChipCore Core SecEMemory is not encrypted,but access is protectedthrough secure world bit;prevents some attacksbut not physical attacksUncoreSecEHardwareMemoryI/O DevicesEmoji Image:https://www.emojione.com/emoji/1f479Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)25
Trusted Processor Chip AssumptionKey to most secure processor architecture designs is the trusted processor chip assumption.Processor ChipCore Core Whole processor chip istrusted.Memory is untrusted.UncoreSystem bus is untrusted.MemoryI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Devices are untrusted.26
Trusted Computing BaseTrusted Computing Base, or TCB, is the sum total of all the hardware and softwarewhich work together to realize the protections offered by the system. TCB is trusted TCB may not be trustworthy, if is not verified or is not bug freeTCB contains: All trusted hardware – typically the processor chip All trusted software – some software levels may be untrusted (e.g. OS in SGX)Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)27
Small TCB AssumptionTo prevent TCB problems, TCB should be small; it is assumed that a smaller hardware and softwareTCB implies better security.The small TCB assumption is derived from: Less software code means it can be audited and verified Less hardware code means it can be audited and verifiedLimitations in today’s security verification tools necessitate the small TCB assumption. Difficult to verify large code bases (both hardware and software) Hard to define all security policies for large, complex systemsTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)28
Open TCB AssumptionKerckhoffs’s Principle from cryptography can be applied to secure architectures: Operation of the TCB should be publicly known and should have no secrets Only secrets are the cryptographic keys Prevent security-by-obscuritySpectre, Meltdown, Foreshadow andother attacks could be attributed tosecurity-by-obscurityaswell.Microarchitectural operation of theprocessor is not (clearly) publiclyknown.Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)29
Today’s Limitations of Secure ArchitecturesThreats which are outside the scope of secure processor architectures: Bugs or Vulnerabilities in the TCB Hardware Trojans and Supply Chain Attacks Physical Probing and Invasive AttacksTCB hardware and software is prone tobugs just like any hardware and software.Modifications to the processor after thedesign phase can be sources of attacks.At runtime hardware can be probed toextract information from the physicalrealization of the chip.Threats which are underestimated when designing secure processor architectures: Side Channel AttacksInformation can leak through timing,power, or electromagnetic emanationsfrom the implementationTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)30
Other Security Related ArchitecturesSecure ProcessorArchitectureSecure Co-Processoror HSM ArchitectureProcessor ChipProcessor ChipCore Core Co-Processor Chip SecurityCrypto UncoreuProcSec. I/OCrypto PUFs CryptographicAcceleratorsProcessor ChipSecurityMonitorProcessor ChipAcceleratorNetwork CardMonitorCryptoCryptoCryptoTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)I/O, Mem.,or Dev.31
Secure Co-Processors or HSMs Hardware security modules (HSMs) are dedicated devicesfor performing cryptographic operations or running secure code Can be attached to the system bus such as PCIe, e.g. IBM cards Can be integrated into SoC design and attack to AXIor similar bus Discrete HSMs typically have tamper resistant and tamperevident coatings, or have battery for backup power Secure co-processors on SoC may lack battery backup,may have lesser physical tamper ryptocards/pciecc/overview.shtmlTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)32
Intel – TPM and TXTCo-processor developed by IBM and others Model: TPM v1.2 Co-processor attaching to chipset Some features advertised by the vendor: crypto engineThe Trusted Platform Module (TPM) is oftenintegrated with other processor security features, e.g.,Intel’s Trusted Execution Technology ot.com/2016/05/intel-sgx-vs-txt.htmlTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)33
Inside Secure – Programmable Root-of-TrustCo-processor IP developed by Inside Secure Model: Programmable Root-of-Trust Co-processor attaching to standard buses Some features advertised by the vendor: crypto accelerators can be synthesized with SypherMediaLibrary (SML) circuit camouflage technologyand anti-reverse engineering side channel protection anti-tamperingCamouflaging can be added to secure debugalmost any design as it is at thelevel of logic gates.Thanks to Benoît De Dinechinfor suggesting to add SoC security e%20IPSOC China 2017 Sept V02 Public.pdfTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)34
Rambus (Cryptography Research, Inc.) – CryptoManagerCo-processor IP developed by Cryptography Research, Inc. (CRI) Model: CryptoManager Root of Trust RT630 Independent hardware security block Some features advertised by vendor: crypto accelerators and DPA resistant crypto “entropic array logic” to thwart reverse engineering canary logic for protection against glitchingand overclocking not susceptible to Spectre and Meltdown secure memoriesProbably due to simple RISC-V anti-temperwithout speculation. Example of secure debugtrading performance for security.Thanks to Benoît De Dinechinfor suggesting to add SoC security ot-of-Trust-RT630-Product-Brief.pdfTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)35
ARM – CryptoCellCo-processor IP developed by Inside Secure Model: CryptoCell-713 Co-processor attaching to ARM’s buses Some features advertised by the vendor: crypto accelerators side channel protection supports Chinese crypto algorithms:SM2 (public key alg. based on elliptic curves),SM3 (hash function), and SM4 (block cipher)Example that cryptographicaccelerators can be for differenttypes of crypto.Thanks to Benoît De Dinechinfor suggesting to add SoC security edTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)36
Synopsys – DesignWare tRoot VxCo-processor IP developed by Synopsys Model: tRoot V500 Hardware Secure Module Co-processor attaching to AMBA bus Some features advertised by the vendor: crypto accelerators secure debug can act as slave device or master devicefor secure boot of the main processorNot just platform to run TEE, butsecurity manager for the wholesystem.Thanks to Benoît De Dinechinfor suggesting to add SoC security php?ds security-troot-hw-secure-moduleTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)37
Microsoft – Pluton Security SubsystemSecurity subsystem for Azure SphereMicrocontrollers (MCUs) Model: Pluton Engine Co-processor attaching to AHB bus Some features advertised by the vendor: crypto acceleratorsThanks to Hanjun Kimfor links to HotChip slides about .13 Microsoft Hardware Security Platform Behind Azure Sphere.pdfTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)38
Other Security Related ArchitecturesSecure ProcessorArchitectureSecure Co-Processoror HSM ArchitectureProcessor ChipProcessor ChipCore Core Co-Processor Chip SecurityCrypto UncoreuProcSec. I/OCrypto PUFs CryptographicAcceleratorsProcessor ChipSecurityMonitorProcessor ChipAcceleratorNetwork CardMonitorCryptoCryptoCryptoTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)I/O, Mem.,or Dev.39
Cryptographic Accelerators Devices for accelerating encryption or decryption Network packets Disk or other storage Can be integrated into the I/O device Network card with crypto tx401Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)40
Other Security Related ArchitecturesSecure ProcessorArchitectureSecure Co-Processoror HSM ArchitectureProcessor ChipProcessor ChipCore Core Co-Processor Chip SecurityCrypto UncoreuProcSec. I/OCrypto PUFs CryptographicAcceleratorsProcessor ChipSecurityMonitorProcessor ChipAcceleratorNetwork CardMonitorCryptoCryptoCryptoTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)I/O, Mem.,or Dev.41
Google – TitanDiscrete chip for snooping on SPI bus and protecting Flash memory with boot ROMs Model: Titan Interposes on SPI communicationto monitor status of flash memorywith boot ROMs Some features advertised by the vendor: crypto accelerators attack detection (glitch, laser, thermal,voltage, or physical probing) boot-time and live-status checksVery important but different from code attestation; focuseson TRNG integrity, clock signal integrity, etc.Thanks to Hanjun Kimfor links to HotChip slides about 14 Google Titan GoogleFinalTitanHotChips2018.pdfTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)42
Secure Processor ArchitecturesTrusted Execution EnvironmentsHardware Roots of TrustMemory ProtectionMultiprocessor and Many-core ProtectionsSide-Channels Threats and ProtectionsSpeculative or Transient Execution ThreatsPrinciples of Secure Processor Architecture DesignTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)43
Trusted Execution Environments and TCBThe goal of Trusted Execution Environments (TEEs) is to provide protections fora piece of code and data from a range of software and hardware attacks. Multiple mutually-untrusting pieces of protected code can run on a system at the same timeThe Trusted Computing Base (TCB) is the set of hardware and software that is responsiblefor realizing the TEE: TEE is created by a set of all the components in the TCB TCB is trusted to correctly implement the protections Vulnerability or successful attack on TCB nullifies TEE protectionsTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)44
TEEs and Software They ProtectDifferent architectures mainly focus on protecting Trusted Software Modules (a.k.a. enclaves)or whole Virtual Machines or AppAppApp GuestOSHypervisor (VMM)Some TEEs have supportfor protecting whole virtualmachines.OtherTEEssupportTrusted Software Modules,a.k.a. enclavesSMMSecEHardwareTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)45
Protections Offered by Secure Processor ArchitecturesSecurity properties for the TEEs that secure processor architectures aim to provide: Confidentiality Integrity Availability (next slide)Confidentiality is the prevention of the disclosure of secret or sensitiveinformation to unauthorized users or entities.Integrity is the prevention of unauthorized modification of protectedinformation without detection.The C. I. A. properties are with respect to components or participants of the system, commonlynamed Alice, Bob, Charlie, Eve, Malory, etc., in different protocolsConfidentiality and integrity protections are from attacks by other components (and hardware) not inthe TCB. There is typically no protection from malicious TCB.Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)46
Protections offered by Secure Processor ArchitecturesProtections not typically offered: AvailabilityAvailability is the provision of services and systems to legitimate userswhen requested or needed.Single processor is not able to provide availability protection (e.g. anybody can unplug computerfrom power source).Security vs. Reliability:Reliability protections assume random faults or errors, security protections assumes that reliability,i.e. protection from random faults or errors, is already provided by the system, and focuses insteadon the deliberate attacks by a smart adversary.Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)47
Sample Protections Categorized by ArchitectureSecure processor architectures break the linear relationship (where lower levelprotection ring is more trusted):SMM and SecE are alwaystrustedtoday,noarchitectureexploresdesign where these levelsare untrusted.SecETutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)48
Protecting State of the Protected SoftwareProtected software’s state is distributed throughout the processor. All of it needs to be protectedfrom the untrusted components and other (untrusted) protected software.Processor ChipCore Core Reg.FU StateCacheSecEMemoryUncoreI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)49
Enforcing Confidentiality through EncryptionSymmetric key cryptography should be used to protect data going off chipto prevent hardware attacks.Processor ChipCore Encrypted memorycontents and trafficprotect confidentialityof the data. Core KmReg.FU StateCacheSecEEnc.MemoryUncoreI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)50
Enforcing Confidentiality through IsolationSoftware entities can be separated through isolation (controlling address translation and mapping).Processor ChipCore Isolatingregionsonesoftwarefrom ther anduntrusted Core Reg.FU StateCacheSecEMemoryUncoreI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)51
Enforcing Confidentiality through State FlushingState in the processor and elsewhere in the system can be flushed to ensure confidentialityfrom other entities that will later run on the system.Processor ChipCore Core Reg.FU StateCacheSecEMemoryUncoreI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)52
Enforcing Integrity through Cryptographic HashingSymmetric key cryptography should be used to protect data going off chipto prevent hardware attacks.Processor ChipCore l attackers. Core RootHashSecEHashMemoryReg.FU StateCacheUncoreI/O DevicesTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)53
No Side-Effects AssumptionSecure processor architectures assume no side-effects are visible to the untrusted componentswhenever protected software is executing.1. System is in some statebefore protected software runs2. Protected software runsmodifying system state3. When protected software isinterrupted or terminatesthe state modificationsare erasedProcessor ChipCore Core Reg.FU StateCacheSecEMemoryTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)UncoreI/O Devices54
Benign Protected Software AssumptionThe software (code and data) executing within TEE protections is assumed to be benignand not malicious: Goal of Secure Processor Architectures is to create minimal TCB that realizes a TEEwithin which the protected software resides and executes Secure Processor Architectures can not protect software if it is buggy or has vulnerabilitiesCode bloat endangers invalidating assumptions about benign protected software.Attacks from within protected software should be defended.Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)55
Hardware TCB as Circuits or ProcessorsKey parts of the hardware TCB can be implemented as dedicated circuits oras firmware or other code running on dedicated processor Custom logic or hardwarestate machine:Processor ChipCore Most academic proposals Code running on dedicatedprocessor: Core Reg.FU StateCacheSecE Intel ME ARC processoror Intel Quark processor AMD PSP ARM processorVulnerabilities in TCB “hardware” can leadto attacks that nullify the security protectionsoffered by the system.MemoryTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)UncoreI/O Devices56
Trustworthy TCB Execution AssumptionTrustworthiness of the TCB depends on the ability to monitor the TCB code(hardware and software) execution as the system runs.Monitoring of TCB requires mechanisms to: Fingerprint and authenticate TCB code Monitor TCB execution Protect TCB code (on embedded security processor) Virtual Memory, ASLR, Tutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)57
Performance Overhead of Securing TCBImpact of threat model on performance: Protecting against more threats typically adds more overhead Memory encryption and integrity checking are the most expensive part,but really depends on how defense is implemented Secure caches: 1 10% overhead Spectre protections: initially stated 10%, now most 10% Memory encryption: can be 100%More protections, must not mean less performance: Partitioning Randomization is not always badTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)58
Alternatives: FHE, FE, TEEs use trusted hardware and software to protect computation that is done in plaintext.Cryptography-based approaches could be used, but they come attremendous performance cost and are not practical today. FHE – Fully Homomorphic EncryptionFE –Function EncryptionMPC – Multi-Party ComputationRE – Randomized EncodingsGES – Graded Encoding SchemeTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Máté Horváth and Levente ButtyánThe Birth of Cryptographic Obfuscation -- A Surveyhttps://eprint.iacr.org/2015/41259
Secure Processor ArchitecturesTrusted Execution Environments9:30 – 9:45 BreakHardware Roots of TrustMemory ProtectionMultiprocessor and Many-core ProtectionsSide-Channels Threats and ProtectionsSpeculative or Transient Execution ThreatsPrinciples of Secure Processor Architecture DesignTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)60
Root of Trust and the Processor KeySecurity of the system is derived from a root of trust. A secret (cryptographic key)only accessible to TCB componentsProcessor ChipCore Derive encryption and signing keysfrom the root of trustHierarchy of keys can be derivedfrom the root of trustKRKmKSKKPK Core KRSecEMemoryTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Reg.FU StateCacheUncoreI/O Devices61
Root of Trust and Processor KeyEach processor requires a unique secret. Burn in at the factory by the manufacturer(but implies trust issues with manufacturerand the supply chain) E.g. One-Time Programmable (OTP) fuses Use Physically Uncloneable Functions(but requires reliability) Extra hardware to derive keys from PUF Mechanisms to generate and distributecertificates for the keyProcessor ChipCore Core KRSecEMemoryTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Reg.FU StateCacheUncoreI/O Devices62
Secrecy of Root of Trust Key AssumptionThe unique processor key is assumed to be never disclosed to anybody. Manufacturer protects the keys Manufacturer is trusted to never disclose the keysIf using PUFs, then the trusted party doing the enrollment and key generation is trusted Trust enrolling party Or may need on-chip key generation facilityTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)63
Derived Keys and Key DistributionDerived form the root of trust are signing and verification keys. Public key, KPK, for encrypting datato be sent to the processor Data handled by the TCBCertID, KPK Signature verification key, KVK, for checkingdata signed by the processor TCB can sign user keysCertID, KVKProcessor ChipKRKSigKIDCertID, KPKIDCertID, KVKKSKTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Emoji ione.com/emoji/1f3e264
Key Distribution for PUF-based DesignsDesigns that leverage PUF may require users or companies to run their ownkey distribution solutions. Deploy own infrastructure Use a trusted 3rd partyProcessor ChipPUFKRIDKSigKKSKTutorial on Principles of Secure Processor Architecture Design Jakub Szefer (ver. ASPLOS 2019)Emoji ione.com/emoji/1f3e265
Protected Root of Trust AssumptionThe root of trust is assumed to be protected.If keys are burned-in by the manufacturer Secret keys are only known to the manufacturer Manufacturer keeps secure database of the keysIf keys are derive from PUFs: Keys are certificates are generated on-chip Or, generated keys are only available to trusted enrolling party New keys can be regenerated or it is known if key was already generated and ”locked”Tutoria
Principles of Secure Processor . most privileged mode that a typical system administrator has access to. Ring -2 System management mode . Operation Normal Operation Ring -1 Normal Ring 0 Normal Ring 3 Normal Ring -1 Privileged Ring 0 Privileged Ring 3 Privileged 21. Breaking Linear Hierarchy of Protection Rings
Alfa Romeo 145 old Processor new Processor 2004 146 old Processor By new Processor DIGA-Soft.de 147 Eeprom 147 NEC-Processor 156 before 2002 Cluster-Plug since 2002 Cluster-Plug 159 Eeprom 166 Processor Model 2002 Eeprom Spider Processor GT Eeprom GTV Processor All JTD (Diesel)
Page 7 of 20 Background on AMD Secure Processor The AMD Secure Processor is a security subsystem introduced by AMD in 2013.On the new Zen architecture, Secure Processor has been thoroughly revised to incorporate advanced features such as Secure Memory Encryption (SME), Secure Encrypted Virtualization (SEV) and Firmware Trusted Platform Module (fTPM).
Architecture vs Micro-architecture Architecture: ! Parts of processor design needed to write programs in assembly ! What is visible to s/w E.g Number of registers Micro-Architecture: ! Detail of how architecture is implemented E.g Core frequency of the processor Aside: Processor Speed: Intel Core i7: 1.8 GHz
processor appears as a single processor running a single C program. This is very different from some other parallel processing models where the programmer has to explicitly program multiple independent processor cores, or can only access the processor via function calls or some other indirect mechanism. The processor executes a single instruction
- The annoying post office dispatch of the equipment is void. . Alfa Romeo 145 old Processor new Processor . 147 NEC-Processor 156 before 2002 Cluster-Plug since 2002 Cluster-Plug 159 Eeprom 166 Processor Model 2002 Eeprom Spider Processor GT Eeprom GTV Processor All JTD (Diesel) Motor-Control Unit .
3050 SFF Intel i 5-7 00. Puertos y ranuras: factor de forma pequeño 1. Botón de encendido 2. . Small Form Factor Height: 289.6 mm Weight (Approximate): 5.14 kg Width: 94 mm Processor & Chipset Processor Generation: 7th Gen Processor Manufacturer: Intel Processor Model: i5-7500 . Processor Speed: 3.40 GHz Processor Type: Core i5 Software .
ThinkPad X1 Titanium Yoga Gen 1 PSREF Product Specifications Reference ThinkPad X1 Titanium Yoga Gen 1 - December 08 2022 1 of 8. PERFORMANCE Processor Processor Family 11th Generation Intel Core i5 / i7 Processor Processor** Processor Name Cores Threads Base Frequency Max Frequency Cache Memory Support Processor Graphics
a speci c, commonly used, case of secure computation. To implement secure computation and secure key storage on mobile platforms hardware solutions were invented. One commonly used solution for secure computation and secure key storage is the Secure Element [28]. This is a smart card like tamper resistant
