1 / 45

Research Issues in Secure and Trusted Computing

Research Issues in Secure and Trusted Computing. Mahadevan Gomathisankaran Princeton University. Outline. Introduction Arc3D Testing Framework Future Plan. Grand Research Challenges *. Eliminate epidemic attacks by 2014 Enable trusted systems for important societal applications

roland
Download Presentation

Research Issues in Secure and Trusted Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Research Issues in Secure and Trusted Computing Mahadevan Gomathisankaran Princeton University M. Gomathisankaran

  2. Outline • Introduction • Arc3D • Testing Framework • Future Plan M. Gomathisankaran

  3. Grand Research Challenges* • Eliminate epidemic attacks by 2014 • Enable trusted systems for important societal applications • Develop accurate risk analysis for cyber security • Secure the ubiquitous computing environment of the future *Computing Research Association (CRA) Conference on “Grand Research Challenges in Information Security & Assurance”, Airlie House, Warrenton, Virginia, November 16-19, 2003 M. Gomathisankaran

  4. Problem Space • Security Attributes • Confidentiality, Integrity, Availability, Accountability and Assurance • Security Goals • Prevention, Detection and Recovery • Trust Attributes • Secure, Measurable and Verifiable M. Gomathisankaran

  5. My Research Focus(so far..) • Security Attributes • Confidentiality, Integrity, Availability, Accountability and Assurance • Security Goals • Prevention, Detection and Recovery • Trust Attributes • Secure, Measurable and Verifiable • Design Principle • Trust no software but enforce security with trustworthy hardware mechanisms M. Gomathisankaran

  6. My Research Projects • Arc3D • Secure Architecture providing confidentiality and integrity • TIVA • Software integrity measurement and verification architecture • Boolean gate based Cryptography • Using Boolean gates to build cryptographic functions • Testing Framework • Virtualization based testing framework to validate security properties M. Gomathisankaran

  7. Outline • Introduction • Arc3D • Testing Framework • Future Plan M. Gomathisankaran

  8. Arc3DIntroduction • Problem • Digital Rights Management • Software Piracy accounts for $13B loss (2002) • Loss of Intellectual Property Tamper Resistance S/w A IP S/w A’ S/w Vendor User X IP Protection Copy Protection S/w A User Y M. Gomathisankaran

  9. Arc3DThreat Model • Threat Model • Adversary has no access to generation • S/w vendor is trusted • Adversary has root privileges • OS is untrusted • Adversary has physical access • CPU is the only trusted element Protected S/w OS Hardware CPU M. Gomathisankaran

  10. Arc3DOur Solution • IP Protection • Obfuscate program • Tamper Resistance • Derived from obfuscation • Copy Protection • Unique Public-Private key pair • Using PKI M. Gomathisankaran

  11. Arc3DProgram Characteristics • Program • Static image - disk • Sequence of instructions and data • Correlation between static image and run-time sequence • Dynamic image - memory • what(contents), where(address) and when(time) M. Gomathisankaran

  12. Arc3DObfuscation • Obfuscating a Program • Encryption • Does not mask the sequence • Adversary with physical access can observe behavior • Our approach • Light-weight (performance) • Protects both sequence and contents M. Gomathisankaran

  13. Arc3DObfuscation • Obfuscation Schema - Basics • Permute the sequence • Apply one-time-pads (OTP) to the contents Input Program OTP Permuted Program Obfuscated Program I1 I2 O1 I2 + O1 I2 I5 O2 I5 + O2 Address I3 I1 O3 I1 + O3 π I4 I3 O4 I3 + O4 I5 I4 O5 I4 + O1 Secret M. Gomathisankaran

  14. Arc3DObfuscation • Obfuscation • One level is not sufficient • Correlation between static and dynamic image • Dynamic obfuscation is necessary • To remove the correlation S/w Vendor Disk CPU Memory S/w Image S.Obf S/w Image Dynamic Obfuscation D.Obf S/w Image Static Obfuscation (during generation) M. Gomathisankaran

  15. Arc3DPermutation Function • Design • Boundary • Cache blocks and Page • Choosing “n” – size of permutation • 10 bits = 1024 cache blocks in a page • There are 1024! permutation functions • Representation ~ 10K bits (Stirling’s approximation) • Defining Subset • Subset of size linear in n should be chosen • Use reversible gates (Toffoli, Fredkin) to build this subset • Implementation • Reconfigurable Logic • Requires 39 (<<< 10K ) bits to represent a permutation function • Implements ~ 239 10 bit permutation functions M. Gomathisankaran

  16. Arc3DOne-Time Pads • Design • One OTP per cache-block impractical • Reusing OTPs • Associate multiple cache-blocks with one OTP • Keep the association secret M. Gomathisankaran

  17. Arc3DObfuscation Schema • Obfuscation Schema • Every program has two pages of OTPs • One for static obfuscation • One for dynamic obfuscation • Every program page has two permutation functions (π1, π2) • π1 permutes the cache-blocks • π2 permutes the assignment of OTP • Applied twice • Static Obfuscation – during binary distribution • Dynamic Obfuscation – during loading into memory M. Gomathisankaran

  18. Arc3DObfuscation Schema Input Page (i) Obfuscated Page (i) Permuted Page (i) Obfuscated Page (i) Permuted Page (i) I1 I2 I2+O3 I4+O2 I4+O2+P2 I2 I5 I5+O4 I2+O3 I2+O3+P5 Address I3 I1 I1+O1 I3+O5 I3+O5+P4 πs1 πd1 I4 I3 I3+O5 I5+O4 I5+O4+P1 I5 I4 I4+O2 I1+O1 I1+O1+P3 OTP Page (s) OTP Page (d) O1 O3 P1 P2 O2 P2 O4 P5 O3 P3 O1 P4 πs2 πd2 O4 O5 P4 P1 O5 O2 P5 P3 Dynamic Obfuscation (during loading) Static Obfuscation (during generation) M. Gomathisankaran

  19. Arc3DArchitecture • Root of Trust • Unique Public-Private key pair • TLB • Extended to store the obfuscation configuration bits • Registers • Separate protected bank • Instructions • start, exit, save, restore, transfer, return • Cache • Extended tag bits for L1 cache • On-chip L2 cache • Protected cache of one page size (64KB) • New functional units • Obfuscation unit, Cryptographic functions, RNG • On-Chip storage • Space to store OTPs M. Gomathisankaran

  20. Arc3DUsage • Generation by S/w vendor Page 1 Obf. Page 1 KS{πs1, πs2} HMAC KS {OTP Page} Page 2 Obf. Page 2 KS{πs1, πs2} HMAC HMAC Page N Obf. Page N KS{πs1, πs2} HMAC Binary Image Extended Binary Image M. Gomathisankaran

  21. Arc3DUsage • Distribution • Verify the authenticity of CPU • Distribute the software by encrypting KS with Pub-Key 1: Pub-Key CPU S/w Vendor 2: Pub-Key 3: Verification CA M. Gomathisankaran

  22. Arc3DUsage • Execution • start • exit • Interrupt Handling • Protected context exists in background • Current PC is stored in the context • return • Context switch between protected applications • save • restore • Fork • transfer M. Gomathisankaran

  23. Arc3DFeatures • Easy task switching • Between protected and unprotected tasks • Protected task context exists in background • Easy integration • Parameters passing through registers • Supports • Fork • Multiple mutually untrustworthy protected tasks M. Gomathisankaran

  24. Arc3DSecurity Analysis • Entry points • Initial starting of the process • Return from interrupt • Context switches • Memory Access • Obfuscation • L1 cache tags • On-chip L2 cache for instructions • Correlation • Dynamic obfuscation M. Gomathisankaran

  25. Arc3DPerformance • Performance Simulation • Simplescalar • Base arch Alpha-21264 • Latencies • Extended TLB access – masked by L1 cache access • TLB miss (~ 12,000 cycles ) • Increased access time to L2 • Performance Impact • Spec 2000 benchmarks • Less than 1% increase in CPI M. Gomathisankaran

  26. Outline • Introduction • Arc3D • Testing Framework • Future Plan M. Gomathisankaran

  27. Testing Framework • Motivation • Framework to test both HW & SW features • Test during design phase in a controlled environment • Check that security properties hold under simulated attacks M. Gomathisankaran

  28. Testing Framework • Goals • Run real-world operating system and applications • Towards a generic platform for any security architecture • Ability to observe and control the System Under Test (SUT) • Launch realistic attacks on hardware & software components M. Gomathisankaran

  29. Testing FrameworkImplementation • Virtual Machine Monitor (VMM) • VMware Workstation (VMAP Program) • Secure Hardware • SP Architecture1,2 • OS • Linux • 1R. B. Lee, P. C. S. Kwan, J. P. McGregor, J. Dwoskin, Z. Wang, “Architecture for Protecting Critical Secrets in Microprocessors”, ISCA 2005, June 2005. • 2J. Dwoskin, R.B. Lee, "Hardware-rooted Trust for Secure Key Management and Transient Trust", ACM CCS 2007, Alexandria, VA, pp. 389-400, October 2007. M. Gomathisankaran

  30. Testing FrameworkArchitecture System Under Test (SUT) Testing System (TS) Software Events/Attacks Application TS Controller TS Proxy Attack Scripts Protected SW Linux Linux TSP Kernel TSC Kernel VMM (hooks added) Event & attack module Event & attack module Security HW Emulator Hardware Events/Attacks M. Gomathisankaran

  31. Testing FrameworkTesting System Controller API M. Gomathisankaran

  32. Testing FrameworkExample • Attack registers on Interrupt • Compromised OS can access process context • Read general registers to extract a key • Modify general registers to change app behavior • TS uses attack script to launch app and control SUT behavior • Exemplifies • Ability to interrupt protected app at the right time • Access internal state (super-powerful) • Modify the application state M. Gomathisankaran

  33. Testing FrameworkExample Attack Script (TS) LoadApp(App, params) // or UnsafeApp // Wait for key generation EventAdd(key_gen) evt Execute() // Get the generated key from Protected Registers (PRs) AccessReg( PR, r, ProtRegs) Key  ProtRegs.Key // Trigger an interrupt Interrupt(03); evt  ExecuteUntil(Interrupt) // Attack confidentiality of general registers (GRs) AccessReg(GR, r, GRegs) if (Key = GRegs.R1) print “Register Confidentiality Attack Succeeded” // Attack integrity of general registers (GRs) AccessReg(GR, w, KnownKey); evt ExecuteUntil(Fault_All) if (evt != Fault_Reg_Integrity) print “Register Integrity Attack Succeeded” Protected Application (SUT) start_prot … Reg1  key_gen(TTP_KeyID) Ciphertext  Encrypt(Reg1, &SecureMem, sz) … end_prot Network_Send(TTP, Ciphertext, sz) … M. Gomathisankaran

  34. Testing FrameworkValidation of HW-SW Security Architecture • Test hardware security mechanisms • Binding protected app to hardware • Protected Execution • Secure Memory • Test software functionality/interface • Example • Key-chain management • Access control on Usage of keys • Secure storage • Test software’s use of secure hardware features • Data flow • Control flow • Data confidentiality • Test system level behavior of the hardware • Page remapping • Entry points M. Gomathisankaran

  35. Outline • Introduction • Arc3D • Testing Framework • Future Plan M. Gomathisankaran

  36. Future Plan • Short term • Port Testing framework to Open-source platform • QEMU, Virtualbox, Xen • Make testing framework generic • Long term • Unified secure and trusted architecture • Protect confidentiality and integrity • Ability to measure at arbitrary point of time • Ability to do arbitrary verification at runtime • Formalize validation • Formal description of secure architecture • Automated generation of attacks M. Gomathisankaran

  37. Publications • Testing Framework • Jeff Dwoskin, Mahadevan Gomathisankaran, and Ruby Lee. Framework for design validation of security architectures. Princeton University Technical Report, CE-L2008-013, 2008. • Secure Architecture • Mahadevan Gomathisankaran and AkhileshTyagi. Architecture Support for 3D Obfuscation. IEEE Trans. Computers 55(5): 497-507, 2006. • Mahadevan Gomathisankaran and AkhileshTyagi. Arc3D : A 3D Obfuscation Architecture. High Performance Embedded Architectures and Compilers (HiPEAC) 184-199, 2005. • Mahadevan Gomathisankaran and AkhileshTyagi. How to Hide Secrets from Operating System: Architecture Level Support for Dynamic Address Trace Obfuscation. Iowa State University Technical Report, 00000101, 2004. M. Gomathisankaran

  38. Publications • Trusted Integrity Verification • Mahadevan Gomathisankaran and AkhileshTyagi. TIVA : Trusted Integrity Verification Architecture.DRMTICS : Technologies, Issues, Challenges and Systems, First International Conference, DRMTICS 2005, Sydney, Australia, October 31 - November 2, 2005. • Boolean Gate Cryptography • Mahadevan Gomathisankaran, Ka-Ming Keung, and AkhileshTyagi. REBEL: Reconfigurable Block Encryption Logic.International Conference on Security and Cryptography (SECRYPT), 2008. • Mahadevan Gomathisankaran and AkhileshTyagi. Relating Boolean Gate Truth Tables to One-Way Functions. IEEE International Conference on Electro/Information Technology Iowa State University Ames, IA, 2008. M. Gomathisankaran

  39. Publications • Others • Mahadevan Gomathisankaran and AkhileshTyagi. WARM SRAM : A Novel Scheme to Reduce Static Leakage Energy in SRAM Arrays.J. Low Power Electronics 2(3): 388-400, 2006. • Mahadevan Gomathisankaran and AkhileshTyagi. WARM SRAM : A Novel Scheme to Reduce Static Leakage Energy in SRAM Arrays.ISVLSI 105-114 (IEEE Computer Society), 2004. M. Gomathisankaran

  40. Thank You! • Questions ? M. Gomathisankaran

  41. Testing FrameworkThreat Model Network Sample System Architecture • Network attacks • App buffer overflows • Protocols/MIM • Eavesdropping Protected App Normal App • OS software attacks • Processes • Kernel • System calls • Interrupts • Registers • Memory/TLB • Devices SW Operating System CPU Main memory μProc Core General Registers Disk HW probe • Hardware attacks • Memory • Disk and Network • Display, I/O buses • Processor chip? Cache New Hardware Display, I/O Network Trusted Component Untrusted Component Attack Source M. Gomathisankaran

  42. Testing FrameworkArchitecture System Under Test (SUT) Testing System (TS) Application TS Controller Attack Scripts Protected SW Operating System Operating System Virtual Machine Monitor Events & attacks Security HW Emulator M. Gomathisankaran

  43. Testing FrameworkExample Attack Script LoadApp(App, params) // or UnsafeApp // Wait for key generation EventAdd(DRK_DeriveKey) EventAdd(App_Keygen) evt  Execute() AccessReg(SP, r, SPRegs) SPKey  SPRegs.DerivedKey AppKey  evt.param1 // Trigger an interrupt Interrupt(03); evt  ExecuteUntil(Interrupt) // Attack confidentiality of general registers (GRs) AccessReg(GR, r, GRegs) if (SPKey = GRegs.R1 OR AppKey = GRegs.R1) print “Register Confidentiality Attack Succeeded” // Attack integrity of general registers (GRs) AccessReg(GR, w, KnownKey); evt ExecuteUntil(SPFault_All) if (evt != SPFault_Reg_Integrity) print “Register Integrity Attack Succeeded” Application without TSM (Unsafeapp) // No SP protection … Reg1  App_Generate_Key(TTP_KeyID) TSP_Notify(App_Keygen, Reg1) Ciphertext  Encrypt(Reg1, &Data, sz) Network_Send(TTP, Ciphertext, sz) … Application with TSM (TSMapp) BEGIN_TSM … Reg1  DRK_DeriveKey(TTP_KeyID) Ciphertext  Encrypt(Reg1, &SecureMem, sz) END_TSM Network_Send(TTP, Ciphertext, sz) … M. Gomathisankaran

  44. Testing FrameworkConclusions • Rapid prototyping vehicle for black-box or white-box security testing of new architectures • Combined HW + OS + App level attacks are realizable • Platform to test SP arch. with different apps and TSMs M. Gomathisankaran

  45. Arc3DArchitecture M. Gomathisankaran

More Related