Source: http://patents.com/us-9971909.html
Timestamp: 2018-12-17 09:27:59
Document Index: 715005303

Matched Legal Cases: ['Application No. 01814609', 'Application No. 01814609', 'Application No. 1948290', 'Application No. 1948290', 'Application No. 2002', 'Application No. 2011', 'Application No. 2011']

US Patent # 9,971,909. Method and apparatus for secure execution using a secure memory partition - Patents.com
United States Patent 9,971,909
Mittal May 15, 2018
Mittal; Millind (Palo Alto, CA)
Family ID: 1000003293191
13/843,215
US 20130298251 A1 Nov 7, 2013
12911640 Oct 25, 2010 8549275
11229669 Oct 26, 2010 7822979
09608439 Jan 6, 2006 6986052
Current CPC Class: G06F 21/72 (20130101); G06F 12/1408 (20130101); G06F 21/602 (20130101); G06F 12/1491 (20130101); G06F 21/60 (20130101); G06F 12/1441 (20130101)
Current International Class: G06F 21/72 (20130101); G06F 12/14 (20060101); G06F 21/60 (20130101)
4573119 February 1986 Westheimer et al.
4987595 January 1991 Marino et al.
5237616 August 1993 Abraham
5249232 September 1993 Erbes et al.
5471599 November 1995 Brodnax et al.
5493665 February 1996 Eisenberg
5559960 September 1996 Lettvin
5592616 January 1997 Finch et al.
5627987 May 1997 Nozue et al.
5668973 September 1997 Stutz et al.
5717942 February 1998 Haupt et al.
5761716 June 1998 Byrn
5799185 August 1998 Watanabe
5835594 November 1998 Albrecht et al.
5841869 November 1998 Merkling et al.
5870520 February 1999 Lee et al.
5875464 February 1999 Kirk
5883956 March 1999 Le et al.
5884026 March 1999 Kong
5892944 April 1999 Fukumoto et al.
5982887 November 1999 Hirotani
5995623 November 1999 Kawano et al.
6003117 December 1999 Buer
6052780 April 2000 Glover
6064989 May 2000 Cordery
6105113 August 2000 Schimmel
6141756 October 2000 Bright et al.
6152367 November 2000 Kowalski
6157398 December 2000 Jeddeloh
6971022 November 2005 Katta et al.
9305183 April 2016 Mittal
9323954 April 2016 Mittal
2004/0177261 September 2004 Watt
2005/0166069 July 2005 Hashimoto et al.
42 17 444 Dec 1992 DE
0 473 913 Mar 1992 EP
0 600 112 Jun 1994 EP
0930 567 Jul 1999 EP
0 965 903 Dec 1999 EP
1 030 237 Aug 2000 EP
1 055 989 Nov 2000 EP
1 056 014 Nov 2000 EP
0 892 521 Jan 2003 EP
1483282 Aug 1977 GB
S57-81650 May 1982 JP
S57-83850 May 1982 JP
64-021637 Jan 1989 JP
09-160831 Jun 1997 JP
10-228421 Aug 1998 JP
10-333902 Dec 1998 JP
2000-076139 Mar 2000 JP
97/29567 Aug 1997 WO
98/34365 Aug 1998 WO
98/44402 Oct 1998 WO
00/23875 Apr 2000 WO
00/62232 Oct 2000 WO
01/27723 Apr 2001 WO
01/27821 Apr 2001 WO
01/75564 Oct 2001 WO
01/75565 Oct 2001 WO
01/75595 Oct 2001 WO
02/03208 Jan 2002 WO
02/17555 Feb 2002 WO
02/086684 Oct 2002 WO
03/058412 Jul 2003 WO
Notice of Allowance received for U.S. Appl. No. 14/583,051, dated Dec. 16, 2015, 8 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,054, dated Mar. 16, 2016, 8 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,056, dated Apr. 12, 2016, 7 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,060, dated Nov. 25, 2015, 8 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,061, dated Mar. 14, 2016, 7 pages. cited by applicant .
Final Office Action received for U.S. Appl. No. 14/583,062, dated Mar. 11, 2016, 9 pages. cited by applicant .
IBM Corporation, "IBM ThinkPad T30 notebooks", Perfect Balance of Performance and Portability, IBM, Apr. 2002, 6 pages. cited by applicant .
Intel Corporation, "IA-32 Intel Architecture Software Developers Manual", vol. 3: System Programming Guide, 2003, 43 pages. cited by applicant .
Intel Corporation, "IA-64 System Abstraction Layer Specification", XP-002253057, Jan. 2000, 48 pages. cited by applicant .
Intel Corporation, "Intel 82802AB/82802AC Firmware Hub (FWH)", Datasheet, XP-002257561, Nov. 2000, 18 pages. cited by applicant .
Intel Corporation, "Inte1386TM DX Microprocessor 32-BIT CHMOS Microprocessor with Integrated Memory. Management", Dec. 1995, 57 pages. cited by applicant .
Karger, et al., "A VMM Security Kernel for the VAX Architecture", IEEE, May 1990, 19 pages. cited by applicant .
Kashiwagi, et al., "Design and Implementation of Dynamically Reconstructing System Software", IEEE, Aug. 1996, 11 pages. cited by applicant .
Kuhn, Markus, "The TrustNo 1 Cryptoprocessor Concept", CS555 Report, Apr. 30, 1997, 6 pages. cited by applicant .
Lawton, Kevin P., "Running Multiple Operating Systems Concurrently on an IA32 PC Using Virtualization Techniques", last modified Nov. 29, 1999, 31 pages. cited by applicant .
Luke, et al., "Replacement Strategy for Aging Avionics Computers", IEEE, AES Systems Magazine, Mar. 1999, 6 pages. cited by applicant .
Menezes, et al., "Handbook of Applied Cryptography", CRC Press LLC, 1997, ISBN: 0-8493-8523-7, 1997, pp. 403-405, 475, 506-515, 570. cited by applicant .
Motorola Inc., "M68040 User's Manual", Motorola, 1990, 97 pp. cited by applicant .
Nanba, et al., "VM/4z ACOS-4 Virtual Machine Architecture", IEEE, 1985, pp. 171-178. cited by applicant .
Richt, et al., In-Circuit-Emulator Wird `Echtzeittauglich`, 2087 Elektronik, vol. 40, No. 16, Aug. 6, 1991, pp. 100-103. cited by applicant .
Robin, et al., "Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor", proceedings of the 9th USENIX Security Symposium, Aug. 14-17, 2000, 16 pages. cited by applicant .
Rosenblum, Mendel, "VMware's Virtual Platform: A Virtual Machine Monitor for Commodity PCs", Hot Chips 11 conference, VMware Inc., Aug. 15-17, 1999, 19 pages. cited by applicant .
RSA Security Inc. "Hardware Authenticators", 2004, 2 pages. cited by applicant .
RSA Security Inc. "RSA SecurID Authenticators: The gold standard in two-factor user authentication", 2003, SID DS 0103, 2 pages. cited by applicant .
RSA Security Inc. "Software Authenticators", 2004, 2 pages. cited by applicant .
Saez, et al., "A Hardware Scheduler for Complex Real-Time Systems", IEEE, ISIE'99-Bled, Apr. 1999, pp. 43-48. cited by applicant .
Schneier, Bruce "Applied Croptography", 1996, 2nd ed., ISBN 0-471-12845-7, John Wiley& Sons. 28-33, 47-52, 56-65,176. cited by applicant .
Sherwood, et al., "Patchable Instruction ROM Architecture", CASES'01, Nov. 16-17, 2001, pp. 24-33. cited by applicant .
Trusted Computing Platform Alliance, "TCPA Main Specification Version 1.0", Jan. 25, 2001, pp. 123-227. cited by applicant .
Trusted Computing Platform Alliance, "TCPA Main Specification Version 1.1a", Dec. 1, 2001, 212 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,061, dated Aug. 1, 2016, 7 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,054, dated Aug. 2, 2016, 7 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 14/583,056, dated Sep. 23, 2016, 8 pages. cited by applicant .
Office Action received for Chinese Patent Application No. 01814609.0, dated Dec. 3, 2004, 9 pages of English Translation only. cited by applicant .
Office Action received for Chinese Patent Application No. 01814609.0, dated Feb. 2, 2007, 5 pages of English Translation only. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 09/608,439, dated Apr. 6, 2004, 10 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 09/608,439, dated Dec. 9, 2004, 15 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 09/608,439, dated Jun. 8, 2005, 4 pages. cited by applicant .
Final Office Action received for U.S. Appl. No. 11/229,669, dated Jan. 30, 2007, 11 pages. cited by applicant .
Final Office Action received for U.S. Appl. No. 11/229,669, dated Sep. 30, 2008, 7 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 11/229,669, dated Apr. 10, 2008, 8 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 11/229,669, dated May 7, 2009, 8 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 11/229,669, dated May 24, 2006, 6 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 11/229,669, dated Nov. 27, 2009, 4 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 11/229,669, dated Jun. 24, 2010, 6 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 11/229,669, dated May 18, 2010, 8 pages. cited by applicant .
Final Office Action received for U.S. Appl. No. 12/911,640, dated Sep. 21, 2012, 7 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 12/911,640, dated Dec. 12, 2011, 9 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 12/911,640, dated Jun. 3, 2011, 34 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 12/911,640, dated May 11, 2012, 9 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 12/911,640, dated Jan. 31, 2013, 5 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 12/911,640, dated May 24, 2013, 8 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 12/977,459, dated Apr. 4, 2012, 9 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 12/977,459, dated Aug. 30, 2012, 5 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 12/977,468, dated Jul. 15, 2011, 40 pages. cited by applicant .
Notice of Allowance received for U.S. Appl. No. 12/977,468, dated Aug. 30, 2013, 9 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,051, dated Jun. 22, 2015, 9 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,054, dated Jun. 30, 2015, 10 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,056, dated Jul. 23, 2015, 10 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,060, dated Jun. 15, 2015, 12 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,061, dated Jun. 24, 2015, 9 pages. cited by applicant .
Non-Final Office Action received for U.S. Appl. No. 14/583,062, dated Jun. 29, 2015, 10 pages. cited by applicant .
Office Action received for European Patent Application No. 1948290, dated Mar. 11, 2010, 4 pages. cited by applicant .
Office Action received for European Patent Application No. 1948290, dated Oct. 22, 2009, 3 pages. cited by applicant .
Office Action received for Japanese Patent Application No. 2002-508208, dated Apr. 26, 2011, 5 pages of English Translation and 5 pages of Japanese Office Action. cited by applicant .
Office Action received for Japanese Patent Application No. 2011-234826, dated Mar. 13, 2012, 6 pages of English Translation and 4 pages of Japanese Office Action. cited by applicant .
Office Action received for Japanese Patent Application No. 2011-234826, dated Sep. 4, 2012, 3 pages of English Translation and 4 pages of Japanese Office Action. cited by applicant .
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US2001/018447, dated Feb. 10, 2004, 3 pages. cited by applicant .
International Search Report received for PCT Patent Application No. PCT/US2001/018447, dated Nov. 14, 2002, 8 pages. cited by applicant .
Berg, Cliff, "How Do I Create a Signed Applet?", Dr. Dobb's Journal, Aug. 1997, 9 pages. cited by applicant .
Brands, Stefan, "Restrictive Blinding of Secret-Key Certificates", CWI, XP-002201306, Springer Verlag, Amsterdam, 1995, 35 pages. cited by applicant .
Chien, et al., "Safe and Protected Execution for the Morph/AMRM Reconfigurable Processor", 7th Annual IEEE Symposium, FCCM '99 Proceedings, ISBN 0-7695-0375-6, Apr. 1, 1999, 13 pages. cited by applicant .
Coulouris, et al., "Distributed Systems: Concepts and Design", Queen Mary and Westfield College University of London, 2nd edition, Addison-Wesley Publishing Ltd., 1998, pp. 422-424. cited by applicant .
Crawford, John, "Architecture of the Intel 80386", IEEE, Jan. 1986, pp. 155-160. cited by applicant .
Davida, et al., "Defending Systems Against Viruses through Cryptographic Authentication", IEEE, Jul. 1989, pp. 312-318. cited by applicant .
Fabry, R.S. "Capability-Based Addressing", Communications of the ACM, vol. 17, No. 7, Jul. 1974, pp. 403-412. cited by applicant .
Frieder, Dr. Gideon, "The Architecture and Operational Characteristics of the VMX Host Machine", IEEE, 1982, pp. 9-16. cited by applicant .
Goldberg, Robert P., "Survey of Virtual Machine Research", Computer, vol. 7, No. 6, Jun. 1974, pp. 34-45. cited by applicant .
Gong, et al., "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2", USENIX, Symposium on Internet Technologies and Systems, Dec. 1997, 11 pages. cited by applicant .
Gum, P.H., "System/370 Extended Architecture: Facilities for Virtual Machines", IBM, J. Res. Develop., vol. 27, No. 6, Nov. 1983, pp. 530-544. cited by applicant .
Heinrich, Joe, "MIPS R4000 Microprocessor User's Manual", 2nd edition, MIPS Technologies, Inc., 1994, pp. 61-97. cited by applicant .
Hewlett-Packard Company, "Mobile Security Overview", Sep. 2002, 10 pages. cited by applicant .
IBM Corporation, "Information Display Technique for a Terminate Stay", IBM Technical Disclosure Bulletin, vol. 34, No. 7A, Dec. 1, 1991, 4 pages. cited by applicant.
This application is a continuation of co-pending U.S. patent application Ser. No. 12/911,640, filed on Oct. 25, 2010, which is a continuation of U.S. patent application Ser. No. 11/229,669, filed on Sep. 20, 2005, issued as U.S. Pat. No. 7,822,979 on Oct. 26, 2010, which is a continuation of U.S. patent application Ser. No. 09/608,439, filed on Jun. 30, 2000, issued as U.S. Pat. No. 6,986,052 on Jan. 6, 2006, entitled "METHOD AND APPARATUS FOR SECURE EXECUTION USING A SECURE MEMORY PARTITION" all incorporated herein by reference.
1. A hardware processor comprising: a register file; cryptographic logic to implement a data encryption algorithm; an execution unit coupled with the register file and the cryptographic logic, the execution unit to execute an instruction to be stored in a secure memory partition of a system memory to include the secure memory partition and an unsecure memory partition; a plurality of caches to cache data from the system memory; logic coupled to the execution unit, wherein the logic is to manage access through virtual addresses and a translation look-aside buffer to the secure memory partition of the system memory; and an address base register, wherein the secure memory partition is defined by the address base register, and wherein the secure memory partition of the system memory has a higher level of security than the unsecure memory partition and is an address range that is to be accessible by a secure kernel having a first security privilege level and that is not to be accessible from a second security privilege level corresponding to application code.
2. The hardware processor of claim 1, further comprising cryptographic logic to implement a data encryption algorithm.
3. The hardware processor of claim 2, wherein the data encryption algorithm is a Data Encryption Standard (DES) algorithm.
4. The hardware processor of claim 1, further comprising a random number generator.
5. The hardware processor of claim 1, further comprising a key storage element to store a private key.
6. The hardware processor of claim 5, wherein the private key is burned into the key storage element.
7. The hardware processor of claim 1, further comprising bootstrap security logic to load instructions from a read-only-memory into the system memory upon system initiation.
8. A hardware processor comprising: a register file; cryptographic logic to implement a data encryption algorithm; a random number generator; an execution unit, coupled to the register file, the cryptographic logic and the random number generator, and to execute an instruction to be stored in a secure memory partition of a system memory to include the secure memory partition and an unsecure memory partition; a plurality of caches to cache data from the system memory; logic coupled to the execution unit, wherein the logic is to manage access through virtual addresses and a translation look-aside buffer to the secure memory partition of the system memory; and an address base register, wherein the secure memory partition is defined by the address base register, and wherein the secure memory partition of the system memory has a higher level of security than the unsecure memory partition and is an address range that is to be accessible by a secure kernel having a first security privilege level and that is not to be accessible from a second security privilege level corresponding to application code.
9. The hardware processor of claim 8, wherein the data encryption algorithm is a Data Encryption Standard (DES) algorithm.
10. The hardware processor of claim 8, further comprising a key storage element to store a private key.
11. The hardware processor of claim 10, wherein the private key is burned into the key storage element.
12. The hardware processor of claim 8, further comprising bootstrap security logic to load instructions from a read-only-memory into a system memory upon system initiation.
13. A system comprising: a display screen; a non-volatile memory; a modem; and a processor coupled to the display screen, the non-volatile memory, and the modem, the processor comprising: cryptographic logic to implement a data encryption algorithm; a key storage element to store a private key; a random number generator; an execution unit coupled to the cryptographic logic, the key storage element, and the random number generator, the execution unit to execute an instruction to be stored in a secure memory partition of a system memory to include the secure memory partition and an unsecure memory partition; logic coupled to the execution unit, wherein the logic is to manage access through virtual addresses and a translation look-aside buffer to the secure memory partition of the system memory, wherein the processor further comprises an address base register, and wherein the secure memory partition is defined by the address base register, and wherein the secure memory partition is an address range that is to be accessible by a secure kernel having a first security privilege level and that is not to be accessible by application code having a second security privilege level.
14. The system of claim 13, wherein the non-volatile memory includes flash memory.
15. The system of claim 13, wherein the data encryption algorithm is a Data Encryption Standard (DES) algorithm.
16. The system of claim 13, wherein the private key is burned into the key storage element.
17. The system of claim 13, further comprising a read-only-memory, the system memory, and bootstrap security logic to load instructions from the read-only-memory into the system memory upon system initiation.
18. A system comprising: a display screen; a non-volatile memory; a modem; and a processor coupled to the display screen, the non-volatile memory, and the modem, the processor comprising: an execution unit to execute an instruction to be stored in a secure memory partition of a system memory to include the secure memory partition and an unsecure memory partition; and logic coupled to the execution unit, wherein the logic is to manage access through virtual addresses and a translation look-aside buffer to the secure memory partition of the system memory wherein the processor also comprises an address base register, wherein the secure memory partition is defined by the address base register, and wherein the secure memory partition is an address range that is to be accessible by a secure kernel having a first security privilege level and that is not to be accessible by application code having a second security privilege level.
19. The system of claim 18, wherein the processor also comprises cryptographic logic to implement a data encryption algorithm.
20. The system of claim 19, wherein the data encryption algorithm is a Data Encryption Standard (DES) algorithm.
21. The system of claim 18, wherein the processor also comprises a random number generator.
22. The system of claim 18, wherein the processor also comprises a key storage element to store a private key.
23. The system of claim 22, wherein the private key is burned into the key storage element.
24. The system of claim 18, further comprising a read-only-memory, the system memory, and bootstrap security logic to load instructions from the read-only-memory into the system memory upon system initiation.
25. The hardware processor of claim 1, wherein the system memory is external to the hardware processor.
26. The hardware processor of claim 8, wherein the system memory is external to the hardware processor.
Securing execution includes ensuring the integrity of the execution and ensuring the privacy of code and data. Various types of threats may lead to a compromise of the integrity or privacy of a system. For example, malicious software may be able to exploit weaknesses in the operating system. Direct memory access devices may be able to read physical memory without processor support. A logic analyzer may be used to observe the traffic between the processor and the memory. Attacks may also be made which take advantage of a processor's built-in debug mode or probe mode or which physically modify the connectivity of components in the system to observe and modify the communication between the components. An attacker could also subject the hardware to an abnormal voltage, temperature or frequency so as to compromise the execution of the system and possibly cause hardware to "leak" out secrets. In addition, an attacker could remove the process layers selectively to expose the device structures hiding the secrets or use an Ion beam to examine the flow of signals inside the device.
FIG. 1 is partial block diagram of a computer system capable of secure execution according to an embodiment of the present invention. Computer 100 contains components 101, which may include a processor 110, chipset 102, system memory 120, network interface card 103, non-volatile mass storage 104, input/output (I/O) device 107, and basic input/output system (BIOS) ROM 108. The processor 110 may be coupled to the chipset 102. The term "coupled" encompasses a direct connection, an indirect connection, an indirect communication, etc. Chipset 102 may also be coupled to system memory 120, network interface card 103, non-volatile mass storage 104, input/output device 107 and BIOS ROM 108. These devices may be coupled to chipset 102 over a bus or busses such as a system bus, peripheral component interface (PCI) bus, etc. Network interface card 103 may be coupled to a network 130. Computer 100 may also contain additional components such as a co-processor, modem, etc.
Processor 110 may be a general purpose microprocessor such as a PENTIUM class processor manufactured by Intel Corp. of Santa Clara, Calif. In another embodiment, the processor can be an Application Specific Integrated Circuit (ASIC), controller, micro-controller, etc. Chipset 102 may be one or more integrated circuit chips that acts as a hub or core for data transfer between the processor and other components of the computer system. In an embodiment, chipset 102 includes a memory control hub (MCH), which performs what is known as "northbridge functionality," and an input/output controller hub (ICH), which performs what is known as "southbridge functionality." System memory 120 is any device adapted to store digital information, such as a dynamic random access memory (DRAM), a static random access memory (SRAM), etc. or any combination thereof. In an embodiment, system memory 120 is a volatile memory. Processor 110, chipset 102, system memory 120, and BIOS ROM 108 may be mounted on a system motherboard in computer 100.
FIG. 2 also shows system memory 220 containing a secure memory partition 223. Secure memory partition 223 may be a section of physical memory or virtual memory that is only accessed by code residing in the secure partition. In one embodiment, secure partition 223 may be defined by two secure partition registers 214. For example, secure partition 223 by a secure partition virtual address base register, which species the start of the secure partition in virtual memory, and a secure partition virtual address range register, which specifies the size of the secure partition. In FIG. 2, secure partition 223 is shown mapped to physical addresses in system memory 220. Secure memory partition 223 may contain a secure data section 225 and a secure code section 226. The secure code section 226 may store, for example, trusted verification enforcement instructions 242 which are used to apply cryptography algorithm and verify the authenticity and integrity of transmissions received over a network (or of content stored on a media such as a DVD or CD-ROM. Secure data section 225 may contain data used by the secure code, such as private keys and intermediate data (e.g., control flow information of the secure instructions). Secure code section 226 may have an entry point 228, which may be used as described below.
In an embodiment, two "security privilege levels" may be defined. One privilege level, referred to as security kernel privilege level, may be for executing only primitive security functions/services. A second privilege level may be defined for executing processor or third-party supplied security code. This second privilege level may be referred to as the applet privilege level. The new security privilege levels (SPLs) may be orthogonal to existing notions of privilege levels of execution. Thus, in this embodiment, the access (execute/read/write) privileges for a given virtual address range become a function of not only Current Privilege Level (CPL) but also current SPL (CSPL). CSPL indicates the security privilege level associated with the current execution. The default value of CSPL may be 3. In this case, when CSPL is 3, the execution model may be is referred to as the default execution model. When CSPL has a value other than default, the execution model is referred to as that of "Hidden Execution" model.
In an embodiment, the secure applet space can only be entered from secure kernel space. In this embodiment, it may be illegal to branch into secure applet space from the default security space, but there may be no restriction on the entry point into secure applet space from secure kernel space. In this embodiment, calling a function in the secure applet space from the address space with default security privilege requires a transfer of control to the fixed entry point in the secure kernel space with proper "credentials" for a request of a function within the current secure applet space. The secure applet address space may exit to the space with a current security privilege level of 3 through any control transfer mechanism. However, if an applet wants to call a function in space with default security, it does so through a function call to its secure kernel space.
In an embodiment, the security extensions define one "secure" partition in the physical memory. If a processor implements only security kernel privilege level, the size of the secure physical space is equal to or greater than the size of the secure kernel space. If a processor supports both security kernel and applet privilege level, then size of the physical partition may be equal to or greater than the sum of the secure kernel and applet spaces. The secure physical memory partition may be defined by a Physical Address Base Register (PABR) and a Physical Address Range Register (PARR). In an embodiment, both the base and the range of secure physical memory partition are fixed at the boot time, and thus are not under control of general system software. Only pre-OS firmware may write to PABR or PARR registers. Thus these registers are write-once only after the reset.
In an embodiment, there are four architectural partitions within the secure address space: 1) secure applet space, 2) secure physical memory associated with applet address space for executing a security kernel function requested by an applet, 3) secure physical memory for kernel code and data, and 4) secure NV memory. Secure physical memory for the applet space, and the portion of secure kernel space associated with the applet execution, may be a per process resource. Secure kernel space may implement a function to save the encrypted version of the content of secure applet physical address space as well as part of the secure kernel space that is reserved for a security kernel function called from secure applet code. Secure kernel address space may also implement a function to restore the secure applet physical memory and a part of the secure kernel space associated with the applet space. These functions enable "virtualization" of secure applet physical memory and the kernel memory associated with the applet space between several processes. The integrity of the swapped-out state may be provided by keeping a hashed value associated with the swapped state in the secure NV memory, along with a "unique tag" corresponding to this instance of the saved state.
In an embodiment, along with unique IDs, processors may also have a private/public key pair. The key pair may be an RSA key pair, DSS key pair, or some other key pair, with RSA being the most advantageous. The private key may be "burned" inside the processor and only used with specific kernel security functions. These security functions may only execute at privilege level cp1.0 (hence within the kernel security space). The public key may also be provided in the processor with the associated certificate. On-chip NV storage may be provided for full private and public keys. It is sufficient to provide storage for enough components that constitute the public and private key such that at power-up the processor is able to compute full keys using on-chip microcode or kernel code without exposing the private key. The part of the public key certificate corresponding to the signed value of the key should be also provided in on-chip NV memory. In an embodiment, an RSA key pair, for 1024 bit private keys, requires 1344 bits of hidden NV storage on the processor: 512 bits for P component, 512 bits for Q component, and 320 bits for the public key certificate (assuming that signature in the certificate are DSS signature).
In an embodiment, the Page Translation Entries formats for virtual to physical mappings for secure address space are defined such that, within secure address space, access rights are only controlled by CSPL. When executing code from any of the secure virtual partitions, performance monitoring capabilities are disabled. Where there may be transitions out of secure kernel or applet space due to interruption or external interrupt, appropriate registers may be saved in a predefined block within secure kernel space. Where there may be external system memory used for saving temporary values in the registers, prior to writing the data within secure address space to external memory, the processor may automatically encrypts the values with an on-chip DES unit using the platform specific "cover key." After saving of these registers in secure physical memory, the corresponding process register values may be changed to some legal, but meaningless, values. For example, most data/address registers may be changed to all "zeros," except EIP may be changed to some fixed legal value.
Transitions out of security address spaces may be handled by on-chip microcode or by an interrupt mechanism within the kernel security virtual address partition. Where external memory is used for the security physical address partitions, some implementations may support fetching encrypted version of instruction stream using DES with platform's "cover-key" from security virtual address partitions.
In an embodiment, there are fixed entry points for the secure kernel space. In this embodiment, a branch to any other offset is illegal. One of the registers may specify the function number to be executed within the security or application address space. Some of the functions may require additional parameters as well, for example input operands, a key to be used for decrypting the target code/data, etc. In an embodiment, no transfer of control into secure applet space from address space with default security (CSPL of 3) is allowed. In another embodiment, cache control bits for secure virtual address space are predefined to select "write-back" attribute for the secure physical space.
Security instructions may be provided to implement the functions of the present invention. These instructions may be classified as either instruction required for supporting the security functions or instructions to improve performance of either security functions, or transitions between different privilege levels. In an embodiment, the minimum native security functions require that the implementation support a kernel security privilege level at "logic analyzer" threat level. The instructions that may be used to support this level of functions are: (1) an instruction to read processor private keys at cp1.0 privilege level, (2) an instruction to write into platform "cover" key and another model specific register at cp1.0 privilege level, (3) an instruction to read a processor's public key, along with its certificate, at any CPL or CSPL, and (4) an instruction to read RNG at any CPL or CSPL.
Other instructions may be defined to facilitate implementations, and to expedite the transitions between address spaces with different security privileges. These may include a branch "hint" instruction to indicate that a upcoming control transfer instruction actually will involve change of Current security privilege level. This instruction may be implemented as an instruction that transfers control to code in the secure applet space, an instruction that transfers control to secure kernel space, and/or an instruction that transfers control to the default security privilege level. Another instruction that may be used is an instruction to store to secure NV memory. This instruction may help implementation by making it known in the front-end, instead of the back-end, of the design that the current store is targeted to NV memory.
There are a large number of options possible for to implement the security kernel space. In one embodiment, the security kernel may implement only one security function. In an further embodiment, the security kernel may support additional functions by simply implementing additional functions in macrocode. In another embodiment, the security kernel may implement a policy of allowing only one function to be invoked by the security driver at a time. In this case, the previous security function should complete before any additional security function execution is initiated. In another embodiment, the security kernel may support only one live function within its resources, but allow virtualization of the secure kernel space by the security driver. This approach may lead to significant overhead for encrypting the state of a partially executed function, and performing integrity checks for a newly loaded function. Another embodiment provides enough space in secure kernel space to allow several security functions to be live simultaneously, and not support "virtualization" of this space.
Registers may be used to manage the secure partition mechanism. These registers may include base and range registers for the secure kernel virtual address space, applet virtual address spaces, physical address space, and non-volatile memory address space. Registers may also be provided to access various processor keys. These may include a register for a processor private key, a register for a processor public key along with signature corresponding to the certificate, and a processor DES "cover-key." The registers may be read only registers.
In an embodiment, the secure kernel and applet address spaces are only defined when the virtual-to-physical translation mechanism is enabled. Security capability may not rely on the OS's memory manager to provide the mapping of the secure virtual address partitions to the secure physical memory. There may be a fixed mapping defined between secure virtual address partitions and secure physical partitions. There may be no provision for access and dirty faults for secure virtual address space, and cache control bits may be set to "write-back" mode. In an embodiment, the OS service is not needed to establish the link between the secure virtual address space and the secure physical address space. In a further embodiment, there is no notion of page faults for these virtual address partitions.
Security level 1 may address the security threats up to the logic analyzer (observe mode) for all hidden execution. When the code in secure physical space is in encrypted form, it is extremely difficult to get access to the processor/platform secrets by modifying the external bus signals actively. However, this security level does not provide any guarantee against such an attack. In a further embodiment, tamper resistance software is used to make "known-text" attacks even hardware. The Security Level 1 model may also provides some protection against use of implementation probe mode and debug hooks to get access to the implementation specific state in order to decipher private data. Additionally, the SL1 model may employ some limited amount of protection against voltage and frequency tampering techniques to make the processor behave incorrectly to get access to the private data.
In the SL-1 model, the protection of the secure partition of the physical memory may be provided by the virtual-to-physical translation mechanism, DES encryption in the processor, and via a physical memory type register in the memory controller. In the SL-1 model, privacy of the secret data may be ensured by operating on the secret data only within the processor storage. Any time data within the secure physical memory address range is written out on the bus, it is encrypted using DES unit in the BIU. For some systems, it is desirable that a DES unit be available for encrypting/decrypting data/code to/from secure physical memory uses platform specific key and not processor specific key.
Previous Patent US 9,971,908 | Next Patent US 9,971,910