WO2014141206A1 - Zone sécurisée sur machine virtuelle pour communications numériques - Google Patents

Zone sécurisée sur machine virtuelle pour communications numériques Download PDF

Info

Publication number
WO2014141206A1
WO2014141206A1 PCT/IB2014/059845 IB2014059845W WO2014141206A1 WO 2014141206 A1 WO2014141206 A1 WO 2014141206A1 IB 2014059845 W IB2014059845 W IB 2014059845W WO 2014141206 A1 WO2014141206 A1 WO 2014141206A1
Authority
WO
WIPO (PCT)
Prior art keywords
secure zone
secure
hypervisor
screen
virtual machine
Prior art date
Application number
PCT/IB2014/059845
Other languages
English (en)
Inventor
Sergey Ignatchenko
Dmitri Ligoum
Original Assignee
Ologn Technologies Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ologn Technologies Ag filed Critical Ologn Technologies Ag
Priority to EP14722732.6A priority Critical patent/EP2973201A1/fr
Priority to CA2902294A priority patent/CA2902294A1/fr
Publication of WO2014141206A1 publication Critical patent/WO2014141206A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot

Definitions

  • the systems, methods and apparatuses described herein relate to the security of computer systems, and in particular, sensitive tasks related to commercial and other data transactions.
  • Figure 1 is a block diagram of an exemplary system according to the present disclosure.
  • Figure 2 is a flow diagram illustrating an exemplary method by which a system according to the current disclosure may accept a task for execution; organize the process of task execution; and cleanup after task execution.
  • Figure 3 is a block diagram of an exemplary processor according to the present disclosure.
  • Figure 4A is a block diagram of an exemplary processor in operation according to the present disclosure.
  • Figure 4B is a mapping of some of the components of the implementation of Figure 1 to the components of the implementation of Figure 4A according to the present disclosure
  • Figure 5 is a flow diagram showing an exemplary process of initializing an exemplary processor according to the present disclosure.
  • Figure 6 is a flow diagram showing an exemplary process of executing a task using an exemplary processor according to the present disclosure.
  • Figure 7 is a flow diagram showing an exemplary process of executing a subtask using an exemplary processor according to the present disclosure.
  • the present disclosure provides systems, methods and apparatuses for securely performing computer-based actions or transactions. For example, it might be desirable to use a computer to establish a secure connection with another user, for example, as a secure text- based chat session, or a secure phone call. In another example, it might be desirable to make a purchase over the Internet.
  • a skilled individual could intercept the data within an operating system running the computer— e.g., even if a chat conversation is encrypted before it is transmitted from one computer to another, each text message could be intercepted within the operating system before it enters the encrypted channel, or payment information could be intercepted and/or modified after it is decrypted— by, for example, installing malware (such as a virus, a keylogger or a Trojan horse) into the operating system of the user's computer.
  • malware such as a virus, a keylogger or a Trojan horse
  • a computer processor may have a hypervisor to initialize and monitor execution of a plurality of virtual machines.
  • the hypervisor may initialize and monitor a secure zone implemented in one or more virtual machines on the computer processor and a non-secure zone, such as a regular operating system, implemented on a separate virtual machine.
  • the secure zone may have a supervisor in one virtual machine and communicate with the non-secure zone via an interface based, for example, on a memory block allocated by the hypervisor for the communication between the secure zone and non-secure zone.
  • the virtual machine for the secure zone may also execute secure tasks.
  • each secure task may be executed on a separate virtual machine.
  • the hypervisor may implement some or all functionality of the supervisor .
  • the supervisor may be created on demand. That is, the supervisor may be initialized and executed only if there are secure tasks that need to be executed.
  • Figure 1 shows one example by which a secure zone 150 according to the present disclosure may be implemented in a larger device 120, such as a computer, laptop, smart phone, television set, personal music player, set-top box, etc.
  • a secure zone 150 according to the present disclosure may be implemented in a larger device 120, such as a computer, laptop, smart phone, television set, personal music player, set-top box, etc.
  • a computing device having a secure zone is disclosed in U.S. Provisional Patent
  • a secure zone 150 may first comprise an interface 151 to one or more non-secure zones 152.
  • non-secure zone refers to any device, processor, operating system, or other object, or combination thereof, which is capable of providing messages, codes, tasks or other information to a secure zone 150.
  • the interface 151 may be configured to receive these messages, codes or tasks from those non- secure zones 152. Exemplary techniques of implementing the interface 151 are described herein.
  • a secure zone 150 may further comprise a supervisor 160 coupled to the interface 151.
  • the supervisor 160 may be used to control access to the components of the secure zone 150, and may be used to enforce certain operational rules of the secure zone 150, providing certain security assurances to the end-user.
  • the supervisor 160 may be configured to: (1) receive executable code which can be run on one or more secure processors 162 within the secure zone 150 via the interface 151; (2) check that certain requirements (as described in greater detail below) are fulfilled for this code; (3) if requirements are fulfilled, load this code into one or more instruction memories 164 located within the secure zone 150; (4) clear one or more data memories 165 located within the secure zone 150; (5) instruct the secure processor 162 to execute code loaded into the instruction memory 164; (6) control one or more indicators 193, which may be used to signal to a user that the secure zone 150 has assumed control of the computing device 120; (7) control one or more peripherals within the computing device 120; (8) provide visual feedback to the end-user about the origin of the loaded code and (9) clean up (to the extent required) after the code has been executed.
  • the supervisor 160 may be configured to: (1) receive executable code which can be run on one or more secure processors 162 within the secure zone 150 via the interface 151; (2) check that certain requirements (as described in greater detail below) are
  • the secure zone 150 may also comprise a secure processor 162, an instruction memory 164 and a data memory 165.
  • the secure processor 162 may be configured to execute code loaded into the instruction memory 164 and to exchange data with the nonsecure zone 152 through the interface 151.
  • Figure 1 shows the secure processor 162 as having a so-called "Harvard architecture" (with separate instruction memory 164 and data memory 165), other architectures (like the ubiquitous von Neumann architecture) may be used as long as equivalent instruction and data restrictions are enforced by the supervisor 160.
  • the XN bit may be used in ARM® processors to provide some separation of data memory from instruction memory, as long as the XN bit in appropriate memory areas is enforced by the supervisor 160 and cannot be altered by code running on the secure processor 162. Similar separation may be achieved on x86 architecture by using the NX bit (also known as the XD bit on INTEL® CPUs and as Enhanced Virus Protection on AMD® CPUs).
  • NX bit also known as the XD bit on INTEL® CPUs and as Enhanced Virus Protection on AMD® CPUs.
  • the secure zone 150 may further comprise one or more cryptographic engines represented by a cryptographic engine 121 shown in Figure 1.
  • the cryptographic engine 121 may be configured to implement one or more symmetric and/or asymmetric cryptographic algorithms, such as Advances Encryption Standard (AES) algorithm, the Rivest-Shamir-Adleman (RSA) algorithm or any other existing or future- developed cryptographic algorithm.
  • AES Advances Encryption Standard
  • RSA Rivest-Shamir-Adleman
  • the cryptographic engine 121 may receive data from the supervisor 160 for encryption or decryption, and may provide the resulting ciphertext (or plaintext, as appropriate) back to the supervisor 160.
  • the supervisor 160 may provide the resulting ciphertext (or plaintext, as appropriate) back to the supervisor 160.
  • the ciphertext or plaintext, as appropriate
  • the cryptographic engine 121 also may be used by the secure processor 162; in this case, it may be desirable to have a clear separation between any cryptography-related tasks coming from the supervisor 160 to the crypto engine 121 and any cryptography-related tasks coming from the secure processor 162 to the crypto engine 121, so as to avoid any leaks of information associated with one component to the other.
  • the secure zone 150 may also comprise a random number generator (RNG) 124 to provide support to cryptographic processes.
  • RNG random number generator
  • the supervisor 160 and/or the secure processor 162 may be configured to perform some or all of the functionality of the cryptographic engine 121 and/or random number generator 124, and a separate cryptographic engine 121 or RNG 124 may not be required.
  • the secure zone 150 may further comprise a decoder 122.
  • the secure zone 150 receives encrypted media content from the non-secure zone 152 (such as from a video player application 112 running within the operating system 111)
  • the code running on the secure processor 162 might be responsible for decrypting the content
  • the decoder 122 may be responsible for decoding the content.
  • This decoder 122 may comprise, for example, implementations of algorithms such as H.264, VC-1, PNG, JPEG, etc. In some cases, the decoder 122 may also include certain text rendering capabilities.
  • the decoder 122 may be coupled to the secure processor 162, such that decrypted data may pass from the cryptographic engine 121 to the decoder 122.
  • the secure processor 162 may be configured to perform some or all of the functionality of the decoder 122, and a separate decoder may not be required.
  • the secure zone 150 may not provide native support for image and/or video decoding, but may be able to receive and execute code (on the secure processor 162) designed to implement this type of media content processing.
  • the instruction memory 164 and data memory 165 may be implemented as volatile memory.
  • the absence of persistent writable storage for executable code may ensure that no viruses, back-doors, or other malicious code may be installed within the secure zone 150.
  • the secure zone 150 may contain one or more certificate storages, represented by a certificate storage 166 shown in Figure 1, which may be implemented as read-only, non-volatile memory.
  • the certificate storage 166 may store one or more root certificates of one or more Certification authorities (CA), which, in turn, may be used for certificate validation.
  • CA Certification Authority
  • the secure zone 150 may additionally comprise one or more key storages represented by a key storage 167 in Figure 1.
  • the key storage 167 may be implemented, for example, as non-volatile memory and may be used, for example, for the storage of one or more private keys (which can be generated, for example, by the supervisor 160 using RNG 124), one or more corresponding public key(s) or associated digital certificates, and/or a unique device identifier. This information may be used, among other uses, to identify and/or authenticate the computer-based device 120 within which the secure zone 150 is located.
  • a secure zone 150 is meant to be used within the context of a larger computer-based device 120, such as a television or a laptop.
  • the computer-based device 120 may comprise a number of components which are outside the secure zone 150, but may nonetheless assist in the operation of the secure zone 150.
  • the device 120 may comprise traditional input/output devices such as a keyboard 192 or a screen 123.
  • the device 120 may further comprise other I/O devices (such as a mouse, remote control transceivers, speakers, or cameras).
  • the device 120 may further comprise a communications port 118, enabling the device to communicate with other devices.
  • the communications port 118 may be useful in creating a connection between the device 120 and a remote computer over a network connection.
  • such a computer-based device 120 may run an operating system 111 and one or more applications 112.
  • the device 120 also may comprise a means for indicating when the device 120 is operating in secure mode, shown on Figure 1 as "indicator” 193.
  • an indicator 193 may be, for example, a green LED which is placed on an outside case of the device 120 and readily visible to a user.
  • a device 120 according to the present disclosure may further comprise additional hardware, software or combination of both allowing it take control of these peripheral components of the device 120 from, e.g., the operating system 111.
  • the secure device 120 may comprise a mixer 181, allowing the secure zone 150 to control the screen 123.
  • the device 120 might also comprise a keyboard switch 194, allowing the secure zone 150 to control the keyboard 192.
  • the same input/output devices may be used to support both non-secure and secure zones.
  • Figure 1 shows components like the mixer 181 and the keyboard switch 194 as implemented outside of the secure zone 150, in some embodiments these components may be placed within the secure zone 150.
  • Figure 2 shows an exemplary method by which a secure zone 150 according to the present disclosure may accept a task for execution; organize the process of task execution; and cleanup after task execution.
  • the interface 151 may receive the code from the non-secure zone 152, and may pass this code to the supervisor 160 for execution by the secure processor 162. It should be understood that whenever code is transferred at step 205, the code may additionally include related application data.
  • the supervisor 160 may clear all data stored within the instruction memory 164 and data memory 165. For example, the supervisor 160 might zero all of the instruction memory 164 and data memory 165. This may be performed to prevent old code, data, or both, from affecting the code currently being loaded, and to avoid information leaks between different pieces of code.
  • the code provider may have encrypted the code (and any related application data) before sending it to the secure zone 150.
  • the code provider may have used a public key corresponding to a private key of the supervisor 160 (which may previously have been stored in the key storage 167, and which may be used by the supervisor 160 to decrypt the code) to encrypt the code.
  • the supervisor 160 may extract a copy of the corresponding private key from key storage 167 and direct the cryptographic engine 121 to decrypt the code (and any associated data, if applicable) using this private key.
  • the code (and any related data) also may have been digitally signed using the code provider's private key, guaranteeing the authenticity of the code.
  • a digital certificate capable of authenticating the code provider may be provided with the code.
  • the code provider may have a private key and a corresponding digital certificate which has been signed by a "root certificate" of a certificate authority.
  • the root certificate previously may have been stored in the certificate storage 166.
  • whole "certificate chains" may be included with the code.
  • alternative ways of obtaining intermediate certificates for example, issuing a request to a server (not shown) via the operating system OS 111 and communications port 118) may be used.
  • the supervisor 160 may instruct the cryptographic engine 121 to validate the digital signature of the code provider.
  • This validation of the digital signature will usually include validation of the certificate received with the code.
  • the supervisor 160 may take a copy of the appropriate VeriSign root certificate from the certificate storage 166 and verify that this root certificate was used to sign the code provider's certificate, performing a typical public key infrastructure (PKI) signature validation; in some cases, a more elaborate validation (for example, including "certificate chains”) may be implemented.
  • PKI public key infrastructure
  • SDSI simple public key infrastructure
  • PGP pretty good privacy
  • the supervisor 160 may additionally perform certificate revocation list (CRL) validation to ensure that all certificates involved in the signature validation are still valid.
  • CRL can be obtained, for example, by means of a request to a server which hosts CRLs. This request can be made, for example, via the operating system 111 and the communications port 118 of the non-secure zone 152.
  • the Online Certificate Status Protocol may be used to check certificate validity (instead of or in addition to CRL validation).
  • the code provider's digital certificate may differ slightly from a traditional certificate, such that it contains not only a text entry capable of identifying the certificate owner (usually the "CN" field of an X.509 digital certificate), indicating the name of the code provider associated with the certificate, but may further contain an image (for example, PNG or JPEG) with a visual representation of the identity of the code provider, as described U.S. Provisional Application 61/623,861.
  • the supervisor 160 may take control of one or more peripherals of the computing device 120 that it needs in order to execute the received code.
  • the supervisor 160 may take control of the keyboard 192 and the screen 123 of the laptop.
  • the supervisor 160 may instruct the keyboard switch 194 to effectively disconnect the keyboard 192 from the non-secure components (such as the operating system 111) and to route all keyboard input to the secure zone 150.
  • the supervisor 160 may also instruct the mixer 181 to combine output from image processor 171 and decoder 122 to form image on screen 123, effectively disconnecting the non-secure zone from the screen 123.
  • the supervisor 160 may provide the "identity image" from the code provider's certificate (which certificate has been validated in step 220) to the image processor 171, and may instruct the mixer 181 to show information from the image processor 171 on a designated area of the screen 123.
  • the supervisor 160 may turn on the indicator 193.
  • the user may confirm that the task is running in the secure zone 150 by checking that the indicator 193 is on, and may confirm that the task was received from a legitimate code provider by verifying that the information displayed in the designated area of the screen 123 (e.g., the code provider's certificate identity image) corresponds to the user's expectations for this task.
  • a legitimate code provider e.g., the code provider's certificate identity image
  • the user may take an appropriate action to halt the task. For example, in some embodiments, the user could press a special key combination on the keyboard 192 to instruct the supervisor 160 to terminate the secure session.
  • the user may similarly take any appropriate action to halt the task.
  • both (i) the identity image should be displayed in the designated area of screen 123 and (ii) the indicator 193 should be on.
  • the code provider may decide that the task does not require provision of a fully secure environment to the user, but rather requires access to the full area of the screen 123 (i.e., "full-screen secure mode").
  • This may be implemented, for example, by setting a boolean flag, indicating whether to use full-screen or partial-screen (i.e., displaying the identity image) mode; to ensure security, supervisor 160 may ensure that indicator 193 is on only in partial-screen secure mode (i.e., when the identity image is displayed) If, at step 230, it is determined that the task should run in full-screen secure mode, the supervisor 160 may grant the secure processor 162 access to the whole screen 123 and proceed to step 245.
  • Full-screen mode might be useful, for example, if the user simply wishes to decrypt and display protected media content he already possesses—the secure zone 150 provides useful technical capabilities (such as the crypto engine 121 and decoder 122)— but does not require the fully secure environment that he might use in situations such as secure communications.
  • the supervisor 160 may load the received code into the instruction memory 164, may store any received application data into the data memory 165, and may instruct the secure processor 162 to begin executing the received code.
  • the supervisor 160 may begin waiting for one or more events related to code execution. For example, at transition 252, code running on the secure processor 162 may request the supervisor 160 to switch into full-screen secure mode and obtain access to the whole screen 123 (i.e., without having the "identity image" being shown). In such a case, as described above, at step 254, the supervisor 160 may turn off the indicator 193 to demonstrate that supervisor 160 no longer controls the output to the screen 123 (and therefore that a designated portion of the screen cannot be used to identify the code provider). The supervisor 160 also may instruct the mixer 181 to show only information from the decoder 122 on the screen 123, effectively granting the whole screen 123 to the code running on the secure processor 162.
  • code running on the secure processor 162 may request the supervisor 160 to switch back into a partial-screen secure mode and redisplay the identity image of the task provider. This may happen, for instance, if a user wished to confirm that the code of the same provider is still running.
  • the supervisor 160 may instruct the mixer 181 to show information from the decoder 122 only on the designated portion of screen 123, while on the other portion the supervisor 160 will begin redisplaying the identity image.
  • the supervisor 160 also may turn on the indicator 193 to assure the user that the displayed is a legitimate identity image.
  • the code running on the secure processor 162 may send a notification back to the supervisor 160 notifying it that code execution has finished, and the supervisor 160 may perform certain steps to transition control back to the non-secure zone 152.
  • the supervisor 160 may display a notification message to the user indicating that a secure task has been abnormally terminated and that the system is about to switch to non-secure mode of operation.
  • the method may wait at step 270 until the user confirms that she has viewed this notification message (for example, by pressing a button on the keyboard). This confirmation may be desirable because, otherwise, the user may have the erroneous perception that the secure task is still running after it has actually abnormally terminated.
  • this notification message may be shown only if the task has changed its state from partial-screen mode to full-screen mode at least once during task execution time.
  • the supervisor 160 may begin a "cleanup" routine and clear all the instruction and data memories 164 and 165 (for example, by zeroing them).
  • the supervisor 160 may shut off the indicator 193.
  • the supervisor 160 may transfer control of any I/O devices back to the non-secure zone 152; for example, it might instruct the keyboard switch 194 to process keyboard 192 input through the operating system 111 of the computing device 120, as well as to instruct the mixer 181 to display information which comes from the operating system 111, on screen 123.
  • Specific types of tasks which may be executed on secure processor 162 within secure zone 150 may include various tasks such as secure chat, media content playback, and so on; examples of some of these tasks are described in U.S. Provisional Application 61/623,861.
  • other types of tasks such as payment tasks similar to the tasks described in U.S. Provisional Patent Application No. 61/636,201, entitled “Secure Zone for Secure Purchases," and filed on April 20, 2012, the entirety of which is incorporated herein by reference, may be executed on the secure processor 162.
  • other types of tasks such as combined tasks that may comprise ordinary and/or indirect subtasks similar to the tasks described in U.S. Provisional Patent Application No. 61/789,618, entitled “Systems, Methods and Apparatuses for Securely Storing and Providing Payment Information," and filed on March 15, 2013, the entirety of which is incorporated herein by reference, may also be executed on the secure processor 162.
  • the non-secure zone 152 and secure zone 150 may be implemented in separate virtual machines executed on a computer processor.
  • Figure 3 is a block diagram of an exemplary processor 500 according to the present disclosure.
  • the processor 500 may comprise a central processing unit (CPU) 505, a read-only memory (ROM) 520, a secure random access memory (secure RAM) 525, a private key storage 530, a secure hardware timer 535, a certificate storage 540 and a RNG 545.
  • the CPU 505, ROM 520, secure RAM 525, private key storage 530, secure hardware timer 535, certificate storage 540, and RNG 545 are logical components of the processor 500 that may be fabricated on a single silicon chip or on multiple chips packaged together.
  • the processor 500 may have a single physical casing that encloses all its components.
  • the processor 500 may be tamper-resistant and/or may use tamper detection techniques.
  • the CPU 505 may perform operations normally performed by a computer CPU that can run one or more virtual machines.
  • the virtual machines may be software implemented virtual machines (for example, using the known paravirtualization technique) and the CPU 505 does not provide any hardware support.
  • the CPU 505 may be a computer processor that supports virtual machines at the hardware level (e.g., by implementing hardware virtualization techniques known in the art and/or new techniques to be developed in the future).
  • Each of the virtual machines may independently execute instructions as if the virtual machine runs on a computer processor exclusive to itself.
  • each virtual machine may have software running on it, such as, an operating system (like Windows, Linux, etc) with applications, or pieces of software requiring no operating system at all.
  • the virtual machines may be controlled by a hypervisor also executed by the CPU 505.
  • the hypervisor may schedule virtual machines to run and enforce rules related to virtual machine access rights to resources (such as peripheral devices, memory blocks, etc). For example, access to the physical memory may be organized such that software running on one of virtual machines will not be able to access memory used by another virtual machine (e.g., allocated to another virtual machine).
  • the supervisor 160 may be implemented as one virtual machine
  • the non-secure zone 152 may be implemented in another virtual machine and each of the tasks to be executed in the secure zone 150 may be executed in separate virtual machines as will be described below.
  • the RNG 545 may be a random number generator similar to the RNG 124 that provides support to cryptographic processes of the exemplary processor 500.
  • the CPU 505 may also perform the functionalities for some components shown on Figure 1, such as the secure processor 162, image processor 171, crypto engine 121, and decoder 122.
  • the ROM 520 may be a non-volatile memory and may be configured such that data stored in the ROM 520 may not be accessed and/or modified from outside the processor 500.
  • the ROM 520 may be fully implemented in hardware to be enclosed within the processor 500.
  • the ROM 520 may be implemented as a non-volatile storage external to the processor 500. If implemented as an external storage, the data stored on the ROM may be encrypted and/or authenticated, and the processor 500 may store an encryption key to decrypt and/or authenticate data loaded from the external storage.
  • An exemplary secure non-volatile storage is described in U.S.
  • the secure RAM 525 may store data that cannot be accessed and/or modified from outside the processor 500.
  • the secure RAM 525 may be implemented as a separate memory inside the processor 500.
  • the secure RAM 525 may be allocated from an existing random access memory already present inside the processor 500 (e.g., an existing L2 or L3 cache). In the latter case, the segment of cache allocated as the secure RAM 525 may be marked as "locked,” that is, the data stored in it should not be exposed outside the processor 500.
  • "locked” may be implemented by permanently marking the cache lines allocated for the secure RAM 525 with two flags: one is the usual "dirty” flag, another is a special '"locked” flag (which may indicate that such a "locked” cache line should never be written to an external main RAM). In some embodiment, the "locked” flag may imply the "dirty” flag.
  • the private key storage 530 may be an exemplary implementation of the key storage 167 and may be used for storing one or more unique private keys labeled 532-1 through 532- M (M being a positive integer). In some embodiments, the key storage 530 may be implemented as a separate hardware unit inside the processor 500. In some other words,
  • the key storage 530 may be a part of the ROM 520.
  • the ROM 520 may be implemented as an external non-volatile storage
  • the keys stored thereon may be encrypted. If the storage 530 is a separate hardware unit inside the processor 500, in one or more embodiments, the content of the storage may be initialized at the time when the processor 500 is manufactured.
  • the secure timer 535 may comprise one or more counters which may be used to determine the time elapsed between the occurrence of two events.
  • a suitable counter may take the form of an oscillator (including, but not limited to a multivibrator) having a known frequency (in which the frequency may be optionally stabilized by using, for example, a quartz crystal resonator) and a digital counter, or any other type of apparatus capable of incrementing a count at a known frequency.
  • the present state of the counter may be recorded (e.g., in a non-volatile memory within the timer 535) at the first event and again at the second event. Then, in conjunction with the known frequency of the counter, the total number of counter increments occurring between the two events may be used to derive the elapsed time in seconds (or whatever other appropriate time measurement).
  • a counter operating at 60 ticks/minute could have value 60 at the time of a first event and 180 at the time of a second event. The difference between the first and second events, in ticks, is 120. Thus, at 60/ticks per minute, it can be calculated that 2 minutes elapsed between the two events.
  • the timer 535 may be implemented so that it cannot be manipulated from outside the processor 500 (but, in some embodiments, time values might be accessible from outside the processor 500 thus implementing read-only access).
  • An exemplary secure timer is described in U.S. Provisional Patent Application No. 61/661,248, entitled “Systems, Methods and Apparatuses for Secure Time Management," and filed on June 18, 2012, the entirety of which is incorporated herein by reference.
  • the certificate storage 540 may be an exemplary implementation of the certificate storage 166 and may store one or more certificate chain root keys labeled 542-1 through 542- L (L being a positive integer). The values of such keys may be stored within the processor 500 at the time when the processor 500 is manufactured. The content of this certificate storage 540 may be protected from modifications from outside the processor 500. In some embodiments, the root keys may be kept unmodified during the lifetime of the processor 500. In one of such embodiments, the certificate storage 540 may be, for example, a part of the ROM 520.
  • the certificate storage 540 may be implemented, for example, as an on-chip non-volatile storage (such as EEPROM or battery-powered static RAM) having enough storage for multiple sets of root keys for the processor 500 to switch between different sets of root keys.
  • an exemplary implementation of secure replacement of root certificates within electronic devices is described in U.S. Provisional Patent Application No. 61/663,266, entitled “Systems, Methods and Apparatuses for Securing Root Certificates," and filed on June 22, 2012, the entirety of which is incorporated herein by reference.
  • two sets of root keys may be stored by an embodiment of the processor 500.
  • the non-volatile storage may have room for storing 10 keys.
  • the nonvolatile storage may contain a one-bit switch to indicate which keyset is currently in use.
  • An exemplary process of updating the root keys may be implemented as follows. At a first stage, the first keyset may contain a set of valid keys in use and the one-bit switch may indicate that the first keyset is in use. Then at a second stage, a key replacement procedure may be processed by the processor 500 to fill a second keyset with a new set of root keys.
  • the one-bit switch may still point to the first keyset and thus, if for any reason processing of the key replacement procedure is not completed, the processor 500 may still function properly using the first keyset and the command may be re-applied if necessary. If the key replacement procedure is completed successfully, the second keyset may have a valid set of root keys. Then at a third stage, the processor 500 may start using the second keyset and the one-bit switch may be changed to indicate that the second keyset is in use.
  • the ROM 520 may be implemented as an updatable secure external non-volatile storage and thus, in some embodiments, the certificate storage 540 may be implemented as a part of the ROM 520 in the updatable secure external non-volatile storage.
  • the root keys may be updatable as well. For example, initially, a first secure external non-volatile storage may store a set of valid keys that may be encrypted with a symmetric key stored within the processor 500. Then, a certificate replacement message to replace the root key may be received and processed by the processor 500. In processing the certificate replacement message, a second non-volatile storage may be prepared to store a new set of root keys (which may be encrypted with a new symmetric key).
  • the symmetric key stored within the processor 500 may still be the key used to encrypt the root keys stored in the first non-volatile storage.
  • the processor 500 may still restart with the symmetric key and the key replacement procedure may be re-applied if necessary.
  • the symmetric key stored within the processor 500 may be changed to the new symmetric key (the one used for encrypting the root keys on the second non-volatile storage).
  • Figure 4A is a block diagram showing the exemplary processor 500 in operation according to the present disclosure.
  • the logical structure of the entities running on the CPU 505 is shown in detail on Figure 4A while other components of the processor 500 (shown in dashed line in Figure 4A) may be skipped for simplicity.
  • Figure 4B shows a mapping of some of components on Figure 1 to components of the CPU 505.
  • the supervisor 160 of Figure 1 may be implemented as a virtual machine (referred to as VM-S 612), the non-secure zone 152 (with an ordinary operating system and applications running thereon) may be implemented as another virtual machine (referred to as VM-NS 614), and a task to be executed in the secure zone 150 may be executed in yet another virtual machine (referred to as VM-T 616).
  • a segment of physical memory (referred to as NS Bus memory block 618) may be allocated to implement the interface 151 between the secure zone 150 and non-secure zone 152.
  • the instruction memory 164 and data memory 165 may be implemented as memory blocks referred to as instruction memory block 622 and data memory block 624 respectively.
  • another segment of physical memory may be allocated to be a task interface memory block 620, which may be used for implementing any interface provided by the supervisor 160 to tasks.
  • the CPU 505 may also run a hypervisor 605 that may control the execution of the virtual machines and allocation of memory blocks. Moreover, the hypervisor 605 may control mapping of peripheral devices to one of the virtual machines. Changing mapping of peripheral devices by the hypervisor 605 may be used to effectively implement the keyboard switch 194 and mixer 181. For example, each peripheral device (e.g., the indicator 193, keyboard 192, screen 123 and communications port 118, etc.) may have its default mappings and the hypervisor 605 may map the peripheral devices (directs their input/output) at the system start according to this default mapping.
  • each peripheral device e.g., the indicator 193, keyboard 192, screen 123 and communications port 118, etc.
  • the hypervisor 605 may map the peripheral devices (directs their input/output) at the system start according to this default mapping.
  • the indicator 193 may be always mapped to the VM-S 612 (and if the VM-S 612 doesn't exist at any moment, the indicator 193 may be turned off by the hypervisor 605).
  • Other devices may be mapped to different virtual machines during operation.
  • the keyboard 192 may initially be mapped to the VM-NS 614 and, during operation, the keyboard 192 may be re-mapped to the VM-S 612 and then back to the VM-NS 614. The details of the re-mapping will be described below with respect to exemplary processes to be performed by the processor 500.
  • the hypervisor 605 may be configured to only grant requests for re-mapping the peripheral devices if they come from the VM-S 612 (and not from any other VM).
  • the mapping may be supported at least in part by hardware level virtualization techniques, such as an input/output memory management unit (IOMMU).
  • IOMMU input/output memory management unit
  • INTEL' S implementation of IOMMU is referred to as Virtualization Technology for Directed I/O (VT-d).
  • the VM-S 612 and hypervisor 605 may have their own respective memories (as well as memory allowing for communication between them, if any) mapped to the secure RAM 525 (which may physically reside within the processor 500).
  • the rest of the memory blocks and cache memory of other virtual machines may be mapped to usual RAM (and reside outside of the processor 500).
  • FIG. 5 is a flow diagram showing an exemplary process 700 of initializing an exemplary processor according to the present disclosure.
  • the exemplary process 700 may illustrate in detail how the virtual machines and the memory blocks of the exemplary processor 500 may be initialized and controlled.
  • the exemplary processor 500 may be powered on to initiate a system boot that may start the hypervisor 605.
  • the hypervisor 605 may be a virtual machine manager that creates and runs virtual machines.
  • the hypervisor 605 may be loaded from the ROM 520.
  • the indicator 193 may be turned off if it's turned on during the system boot.
  • the hypervisor 605 may allocate a block of memory as an interface between the secure and non-secure zones.
  • the NS bus memory block 618 may serve as a communication buffer between the virtual machines VM-S 612 and VM-NS 614.
  • the process 700 may proceed to block 708, at which the hypervisor 605 may initialize a first virtual machine (e.g., the VM-S 612) and load the supervisor 160 into the first virtual machine VM-S 612. Then the supervisor 160 may be executed on the first virtual machine VM-S 612 under the control of the hypervisor 605.
  • the supervisor 160 may be loaded from the ROM 520 to the secure RAM 525 and a reference to the NS bus memory block 618 may be provided to the supervisor 160. Once loaded and started, the supervisor 160 may wait for requests to come through the NS bus memory block 618.
  • the hypervisor 605 may map the indicator 193 to the supervisor 160 running on the first virtual machine VM-S 612. At this point, because the processor 500 may not be executing tasks in a secure mode, the indicator 193 may be kept off by the first virtual machine VM-S 612.
  • the hypervisor may initialize a second virtual machine (e.g., the VM-NS 614) and load a non-secure operating system into the second virtual machine VM-NS 614, and start executing the non-secure operating system on the second virtual machine VM-NS 614 under the control of the hypervisor 605.
  • the hypervisor 605 may provide a reference to the NS bus memory block 618 to the VM-NS 614 (for example, this information may be passed to a driver responsible for communicating with the supervisor 160, such driver may reside in the nonsecure operating system running within the VM-NS 614) to set up the communication interface between the non-secure operating system on the second virtual machine VM-NS 614 and the supervisor 160 on the first virtual machine VM-S 612.
  • the virtual machines for the secure and non-secure zones may be set up and the communication interface between these zones may be ready.
  • the non-secure operating system 111 and applications 112 running on the virtual machine VM-NS 614 may send requests to the supervisor 160 running on the virtual machine VM-S 612 via the communication interface NS bus memory block 618 (for example, via the driver described above). It should be noted that the initialization and loading of the virtual machines VM-S 612 and VM-NS 614 may be performed in any sequence. In another embodiment, the VM-NS 614 may be initialized and loaded first and the VM-S 612 may be initialized subsequently, or both VM-NS 614 and VM- S 612 may be initialized in parallel.
  • FIG. 6 illustrates an exemplary process 800 of executing a task using the exemplary processor 500 according to the present disclosure.
  • the process 800 may start at block 802, at which a request to load and execute a task may be sent from the virtual machine VM-NS 614 that executes the non-secure zone 152 to the virtual machine VM-S 612 that executes the supervisor 160.
  • a request may include one or more blocks of data sent over the NS Bus memory block 618.
  • a request may be sent from the virtual machine VM-S 612 to the hypervisor 605 for allocation of three memory blocks that are needed for executing a task: instruction memory block 622, data memory block 624, and task interface memory block 620.
  • the hypervisor 605 may allocate these memory blocks as a single contiguous memory block or dispersed memory blocks.
  • the virtual machine VM-S 612 may load the task and prepare to execute it. In one embodiment, as described above with respect to Figure 2, in preparing to execute the task, the VM-S 612 may decrypt the task (if applicable), verify the task signatures, clean the memory blocks 620, 622, and 624 (for example, by zeroing them), and load the task code to the instruction memory block 622 and task data to the data memory block 624.
  • the VM-S 612 may send a request to the hypervisor 605 to re-map certain peripheral devices.
  • the virtual machine VM-S 612 may request the hypervisor 605 to re-map the keyboard 192 and screen 123 to the virtual machine VM-S 612.
  • the virtual machine VM-S 612 may save the state of some or all remapped peripheral devices.
  • the indicator 193 may be turned on and other steps related to task initialization may be performed.
  • the virtual machine VM-S 612 may turn on the indicator 193 and performs other steps related to task initialization as described with respect to the exemplary method shown in Figure 2.
  • the hypervisor 605 may be requested to create a virtual machine for the task to be executed thereon.
  • the virtual machine VM-S 612 may request the hypervisor 605 create a virtual machine VM-T 616 using the image residing in the memory blocks 622 and 624.
  • the task interface memory block 620 may be used as a memory buffer to implement an interface between the task and the supervisor. In some embodiments, this request may include a virtual address where the memory block 620 may be mapped within the newly created VM-T 616.
  • the virtual machine VM- S 612 may wait for task related events. For example, the VM-S 612 may wait for requests coming though NS bus memory block 618 and task interface memory block 620 from VM- NS 614 and VM-T 616 respectively, and any input data from the peripheral devices.
  • the process 800 may execute the task on the newly created virtual machine VM-T 616 using the memory blocks 622 and 624.
  • the virtual machine VM-T 616 may have permissions to access only the memory blocks 622, 624, and 620 to execute the task.
  • permissions granted to the VM-T 614 to access memory blocks 620 and 624 may disallow code execution (that is, the code can be executed only if it is located in the block 622, which may be implemented, for example, by using NX bit or XN bit mentioned above) to ensure code and data separation.
  • the supervisor 160 on the VM-S 612 may process the task related events. For example, once the task may be loaded into the virtual machine VM-T 616 and start executing, the VM-S 612 may wait for task related events.
  • the task related events may include, for example, Application Programming Interface (API) calls from the task being executed and notifications from any hardware devices (e.g., the keyboard 192).
  • API calls may include calls from the VM-T 616 (via the interface based on the task interface memory block 620).
  • notifications from the hardware devices may be redirected via the communication interface based on the task interface memory block 620 to the VM-T 616.
  • API Application Programming Interface
  • the supervisor 160 on the VM-S 612 may be notified about the termination of the virtual machine VM-T 616 that executes the task.
  • the hypervisor 605 may monitor the execution of all virtual machines and may notify the VM-S 612 about the termination of execution in the VM-T 616.
  • this notification may contain the reason for the termination (for example, using exit code, error code, or exception code).
  • the process 800 may perform cleanup after the termination of the task virtual machine VM-T 616.
  • the VM-S 612 may turn off the indicator 193 and request the hypervisor 605 to re-map other peripheral devices to the VM-NS 614.
  • the virtual machine VM-S 612 may restore the state of some or all remapped peripheral devices to values saved at the block 808.
  • the hypervisor 605 may clean the memory blocks 622 and 624.
  • the hypervisor 605 may map these memory blocks to the VM-S 612 so that the VM-S 612 may perform the cleanup of these memory blocks (for example, by zeroing them).
  • the virtual machine VM-S 612 for the supervisor 160 may be created "on demand.” In one such embodiment, the virtual machine VM-S 612 for the supervisor 160 may be created only when the virtual machine VM-NS 614 for the non-secure zone 152 tries to initiate a communication with the supervisor 160 via the NS Bus memory block 618. For example, when the VM-NS 614 needs to load a task (or otherwise
  • the hypervisor 605 may send a message to the hypervisor 605 (for example, using a predefined message intended for this purpose). As a result of this message, the hypervisor 605 may load the supervisor 160 to a newly created VM-S 612 and allocate the memory block 618. Once the VM-S 612 is loaded and the memory block 618 is ready, the hypervisor 605 may provide a reference to the NS Bus memory block 618 to the VM-NS 614 and the task can be loaded as described above. When the task is terminated and unloaded (at block 822), the VM-S 612 may remain active (waiting for requests), or the hypervisor 605 may select to unload it. In the latter case, the hypervisor 605 may ensure that the indicator 193 is turned off.
  • a virtual machine e.g., the VM-NS 614 initiating the communication (sending a request, calling an API, etc) may load associated data to the relevant memory block (e.g., NS Bus memory block 618), and then send a notification to the hypervisor 605 to indicate that it wants to communicate the data already loaded into the relevant memory block to a receiving virtual machine (in the above example, to the VM-S 612). Then the hypervisor 605 may forward this notification to the receiving virtual machine (e.g., the VM-S 612).
  • the relevant memory block e.g., NS Bus memory block 618
  • the hypervisor 605 may forward this notification to the receiving virtual machine (e.g., the VM-S 612).
  • the hypervisor 605 may also schedule the receiving virtual machine so that the receiving virtual machine may be able to process the request.
  • the hypervisor 605 may re-map appropriate memory space and enforce a rule that after such a request is formed, only the receiving virtual machine may have access to the relevant memory block (and the virtual machine sending the request may not modify its request anymore).
  • the notification may include a reference to the calling virtual machine (e.g., VM-NS 614) and/or to the relevant memory block to be used for communication (e.g., NS Bus memory block 618).
  • the receiving virtual machine may receive the notification from the hypervisor 605, read a corresponding buffer (e.g., the NS Bus memory block 618), and process the call or notification.
  • a corresponding buffer e.g., the NS Bus memory block 618
  • a virtual machine initiating a communication may first load data relevant to the request to a relevant memory block (for example, the NS Bus memory block 618), and then change a predefined area of memory within that memory block (e.g., a counter value stored in that area).
  • a virtual machine waiting for a notification e.g. the VM-S 612 may periodically check for changes of that predefined area, and if changes are detected, assume that the request has been sent and process the data related to the request.
  • the screen 123 may be used simultaneously by the supervisor 160 and tasks being executed in the secure zone 150, or by tasks being executed in the secure zone 150 and the operating system running in the non-secure zone 152.
  • the portion of the screen generated by different entities may be protected against access by other entities.
  • the screen output generated by either VM-S 612, VM-NS 614, or VM-T 616 may be protected against access by another virtual machine.
  • the VM-S 612 may take control over the screen 123 (e.g., at block 808), and each of the VM-NS 614 and VM-T 616 may prepare their screen data and send the prepared data to the VM-S 612 (using, for instance, corresponding communication interfaces based on the memory blocks 618 and 620 respectively) for the screen data being sent to the screen 123. Since neither virtual machines VM-NS 614 or VM-T 416 has direct access to the screen 123 at any time, none of them may access a portion of the screen unless that access is permitted by the supervisor 160.
  • a video card (not shown) of device 120 may be implemented in a way to appear as three separate devices: (a) a secure screen device; (b) an insecure screen device; and (c) a device which tells which part of the screen is controlled by (a) or (b).
  • the devices (a) and (b) may be configured to not exchange any information between them.
  • the device (c) may define a set of rectangles controlled by the secure device (a).
  • the devices (a) and (b) may have equal capabilities.
  • the capabilities of such devices may differ (e.g., insecure device (b) may support 3D and/or video decoding, while secure device (a) may only support static images).
  • the secure device (a) may support "an alpha-channel" so an image passed to the secure device (a) may overlay images/videos/3D pictures passed to insecure device (b), which may be useful in some specific scenarios, like overlaying gaming status information over insecure 3D picture, etc.
  • the secure device (a) may be, for example, configured by the hypervisor (for example, using IOMMU) to be controlled by VM-T 616
  • the insecure device (b) may be controlled by VM-NS 614
  • the device (c) may be controlled by VM-S 612.
  • Figure 4A illustrates an exemplary processor 500 that has the hypervisor 605 and separate virtual machines VM-S 612, VM-NS 614, and VM-T 616.
  • the hypervisor 605 and the VM-S 612 may be combined so that functionalities of both of them may be performed by one hypervisor.
  • a single hypervisor may implement both functionality of the hypervisor 605 (required to run virtual machines) and functionality of the supervisor 160.
  • the single hypervisor may use the secure RAM 525 for all operations, and the secure RAM 525 may not be mapped to any of the virtual machines.
  • the VM-S 612 and VM-T 616 may be combined into a single virtual machine so that the supervisor 160 logic and tasks may be performed within the same virtual machine.
  • the VM-S 612 may request the hypervisor 605 for the memory blocks 622, 624, and 620.
  • the VM-S 612 may allocate some or all of such memory blocks within its own memory. Then the task may be loaded and executed as a separate process run by a secure operating system running within VM-S 612 (with the secure operating system implementing the supervisor's logic).
  • embodiments of the present disclosure may also execute subtasks, for example, as described in U.S. Provisional
  • FIG. 7 is a flow diagram showing an exemplary process 900 of executing a subtask using an exemplary processor according to the present disclosure.
  • the process 900 may start at block 902, at which the supervisor 160 running on the virtual machine VM-S 612 may receive a request from a task running on the virtual machine VM-T 616 to load a subtask (for example, via the interface based on the task interface memory block 620).
  • the request may contain the subtask to be executed (or, alternatively, an identifier of the subtask which is already known to the supervisor, for example, as a part of loading task process) and the reference to a memory block to be used for data shared between the task and the subtask (such memory block may be implemented similar to memory block used for the task interface memory block 620).
  • the process 900 may proceed to block 904, at which the task (running on the VM-T 616) may be suspended (for example, VM-T 616 may not receive further time slices from the hypervisor until it is resumed in block 908).
  • the subtask may be executed as a separate task.
  • the processor 500 may treat the subtask as a regular separate task and may execute the exemplary process 800 in its entirety (or in substantial part) at block 906.
  • another virtual machine may be initialized, the subtask may be verified and loaded into the newly created virtual machine, executed, and terminated as described above with respect to blocks 802-822.
  • the memory block to be used for data sharing may also be mapped to this newly created virtual machine.
  • an executing subtask virtual machine may have its access to peripheral devices restricted (for example, by the hypervisor 605 as instructed by the supervisor running within VM-S 612) according to the subtask permissions (for example, as mentioned in the subtask certificate). It should be noted that in some cases, subtask permissions may be narrower than task permissions, and in some cases, subtask permissions may be broader than task permissions.
  • the execution of the subtask is terminated, at block 908, the execution of the task in the VM-T 616 may be resumed.
  • the exemplary process 900 illustrates an embodiment in which the supervisor 160 and a task may be executed in separate virtual machines.
  • a subtask may be executed as a separate process.
  • the process running the calling task may be suspended, the subtask may be executed as a separate process, and then the task may be resumed.
  • the memory separation may be enforced by the secure operating system that implements the supervisor.
  • the processor 500 may utilize various virtualization technologies including hardware virtualization technologies developed by CPU manufacturers.
  • the processor 500 may utilize technologies such as AMD-V® and Intel VT-x®. Additionally, to ensure device separation between different virtual machines, the processor 500 may utilize the IOMMU functionality implemented in INTEL or AMD processors.
  • processor 500 may be implemented over an ARM®
  • TRUSTZONE® may be equivalent to having only two virtual machines ("secure world” and "normal world”, plus monitor mode which is functionally similar to the hypervisor) on a single processor.
  • the VM-NS 614 may be in the TRUSTZONE "normal world," and the VM-S 612 may be combined either with the hypervisor 605 under the TRUSTZONE "monitor mode,” or combined with the VM-T 616 under the TRUSTZO E "secure world” (running tasks as separate processes within the VM- S 612).
  • the ARM virtualization extensions may be used in a manner similar to the x86 virtualization technologies.
  • the processor 500 may support two modes of system boot: secure boot mode and insecure boot mode.
  • secure boot mode the system may behave as described above, allowing to boot the hypervisor only from ROM 520.
  • insecure boot mode the processor 500 may allow a non-secure hypervisor or a non-secure operating system to run (i.e. the processor 500 may be allowed to boot from an arbitrary source), while ensuring that there is no access from this non-secure hypervisor (or non-secure operating system) to any (or some of) security features described above.
  • the indicator 193 may always be kept “off, and there may be no access (e.g., read or write (modification)) to data stored in the ROM 520, private key storage 530, or certificate storage 540.
  • the secure timer 535 cannot be reset or somehow modified (but in some embodiments, it may be allowed to be read).
  • a security-enhancing chip external to the processor 500 may be used to implement certain features of the processor 500 as it will be discussed in greater details below.
  • the security-enhancing chip may be connected to the processor 500.
  • both the security-enhancing chip and the processor 500 may be assembled on the same main board and connected via a bus, such as, for example, an I 2 C bus or PCIe bus.
  • the security-enhancing chip may be configured (i) to receive data related to the current hardware (for example, the type of processor, boot mode, etc.) and/or software configuration (for example, a secure hash of the image of a hypervisor, supervisor, etc.), (ii) to create a configuration digest, and (iii) to have one or more shielded locations to store data that may be accessible only by a specific hardware and/or software configuration.
  • a chip implementing similar functionality is a Trusted Platform Module (TPM) as defined in "TCG Specification Architecture Overview
  • TPM Trusted Computing Group
  • the configuration digest mentioned above may be implemented via TPM measurement events (each providing information about properties and characteristics of a measured system component).
  • the TPM measurement events may be then combined (using, for example, a secure hash function) in TPM Program Configuration Registers, as described in the TCG Specification.
  • the shielded locations may be implemented, for example, via TPM "sealing" (such as "Sealed BLOB structures”), using TPM Program Configuration Registers to protect access to the sealed data.
  • the one or more shielded locations may be generated and stored within such a system.
  • it may be stored as an TPM Protected External Storage, such as a sealed BLOB structure, with only encryption keys residing within the TPM, and the data itself residing, for example, in an external ROM (not shown) or on an external TPM Protected External Storage, such as a sealed BLOB structure, with only encryption keys residing within the TPM, and the data itself residing, for example, in an external ROM (not shown) or on an external
  • Such shielded location(s) may be used, for example, to store the certificate storage 540 and/or the private key storage 530 for this system. In some embodiments, this shielded location may be made accessible only if the configuration digest of the current system (e.g., hardware, software, or both) is identical to a pre-specified configuration digest. This may be used to ensure that the current hardware platform is identical to a pre-specified platform, and in embodiments where a secure hash of hypervisor 605 is a part of configuration digest this may ensure that a pre-specified hypervisor 605 (identified, for example, by its secure hash) is currently running.
  • the configuration digest of the current system e.g., hardware, software, or both
  • This may be used to ensure that the current hardware platform is identical to a pre-specified platform, and in embodiments where a secure hash of hypervisor 605 is a part of configuration digest this may ensure that a pre-specified hypervisor 605 (identified, for example, by its secure hash) is
  • the current state of the TPM Platform Configuration Registers may need to be identical to the state of the Platform Configuration Registers which were used to seal the TPM sealed BLOB structure(s).
  • the TPM Platform Configuration Registers contain a secure hash of a hypervisor, it provides assurance that only the specific hypervisor may access the data in the sealed BLOB structure.
  • a configuration digest may include not only a secure hash of the hypervisor, but also, for example, a secure hash of the supervisor.
  • elements of the configuration may include a video card and an indicator 193. This may be used, for example, to ensure that only a platform providing the necessary (software and hardware) elements related to security is considered by the security-enhancing chip as a secure platform, and, correspondingly, only such a platform is granted access to respective shielded locations.
  • the secure timer 535 may be implemented as a part of security-enhancing chip. In other embodiments using a security- enhancing chip, the secure timer 535 may be implemented in software, for example, using one or more shielded locations to store current values securely.
  • the RNG 545 may be implemented by the security-enhancing chip or in software (for example, as a part of the supervisor 160).
  • the usual RAM may be used to implement functionality of the secure RAM 525. This may be a reasonable solution, for example, if the owner of a system that contains the processor 500 considers a physical attack to be unlikely.
  • a processor 500 may not necessarily have components such as the ROM 520, secure timer 535, RNG 545, certificate storage 540, and/or private key storage 530, and therefore, in some of such embodiments, a processor 500 may consist only of the CPU 505.
  • the described functionality can be implemented in varying ways for each particular application- such as by using any combination of microprocessors, microcontrollers, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and/or System on a Chip (SoC)--but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
  • FPGAs field programmable gate arrays
  • ASICs application specific integrated circuits
  • SoC System on a Chip
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • the methods disclosed herein comprise one or more steps or actions for achieving the described method.
  • the method steps and/or actions may be interchanged with one another without departing from the scope of the present invention.
  • the order and/or use of specific steps and/or actions may be modified without departing from the scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un appareil mettant en oeuvre une zone sécurisée sur une machine virtuelle. Dans un aspect, l'appareil peut comprendre un écran et un processeur d'ordinateur. Le processeur d'ordinateur peut être configuré pour initialiser un hyperviseur, créer une première machine virtuelle pour exécuter un code pour une zone sécurisée, et créer une seconde machine virtuelle pour exécuter un code pour une zone non sécurisée. Le code pour la zone sécurisée peut prendre en charge ou transférer le contrôle d'un résultat présenté à l'écran selon que le dispositif fonctionne ou non dans un mode sécurisé. Dans un autre aspect, l'appareil peut également comprendre une puce de renforcement de la sécurité. Cette puce peut comprendre une mémoire permanente pour stocker une clé de chiffrement et une première synthèse de configuration, et peut être configurée pour créer une seconde synthèse de configuration en fonction des données de configuration reçues, et permettre l'accès à la clé de chiffrement en fonction de la comparaison de la première et de la seconde synthèse de configuration.
PCT/IB2014/059845 2013-03-15 2014-03-14 Zone sécurisée sur machine virtuelle pour communications numériques WO2014141206A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP14722732.6A EP2973201A1 (fr) 2013-03-15 2014-03-14 Zone sécurisée sur machine virtuelle pour communications numériques
CA2902294A CA2902294A1 (fr) 2013-03-15 2014-03-14 Zone securisee sur machine virtuelle pour communications numeriques

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361791632P 2013-03-15 2013-03-15
US61/791,632 2013-03-15
US201361808774P 2013-04-05 2013-04-05
US61/808,774 2013-04-05

Publications (1)

Publication Number Publication Date
WO2014141206A1 true WO2014141206A1 (fr) 2014-09-18

Family

ID=50685975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/059845 WO2014141206A1 (fr) 2013-03-15 2014-03-14 Zone sécurisée sur machine virtuelle pour communications numériques

Country Status (3)

Country Link
EP (1) EP2973201A1 (fr)
CA (1) CA2902294A1 (fr)
WO (1) WO2014141206A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106211144A (zh) * 2015-04-30 2016-12-07 华为技术有限公司 一种移动终端的通信方法及移动终端
EP3418934A4 (fr) * 2016-03-15 2018-12-26 Huawei Technologies Co., Ltd. Procédé, dispositif et équipement utilisateur de saisie de données
CN112005237A (zh) * 2018-04-30 2020-11-27 谷歌有限责任公司 安全区中的处理器与处理加速器之间的安全协作
CN112005237B (zh) * 2018-04-30 2024-04-30 谷歌有限责任公司 安全区中的处理器与处理加速器之间的安全协作

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116578390B (zh) * 2023-07-04 2023-09-12 摩尔线程智能科技(北京)有限责任公司 驱动的通信方法、服务器、图形处理器、设备及芯片

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2113855A1 (fr) * 2008-04-28 2009-11-04 Forschungszentrum Karlsruhe GmbH Procédé de gestion et de manipulation de plusieurs systèmes de fonctionnement dans un ordinateur ou réseau d'ordinateurs
WO2011037665A2 (fr) * 2009-08-04 2011-03-31 Carnegie Mellon University Procédés et appareil pour chemin sécurisé vérifiable par l'utilisateur en présence d'un logiciel malveillant

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2113855A1 (fr) * 2008-04-28 2009-11-04 Forschungszentrum Karlsruhe GmbH Procédé de gestion et de manipulation de plusieurs systèmes de fonctionnement dans un ordinateur ou réseau d'ordinateurs
WO2011037665A2 (fr) * 2009-08-04 2011-03-31 Carnegie Mellon University Procédés et appareil pour chemin sécurisé vérifiable par l'utilisateur en présence d'un logiciel malveillant

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GARFINKEL T: "Terra: a virtual machine-based platform for trusted computing", ACM SOSP. PROCEEDINGS OF THE ACM SYMPOSIUM ON OPERATING SYSTEMSPRINCIPLES; 20031019, 22 October 2003 (2003-10-22), pages 193 - 206, XP002340992 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106211144A (zh) * 2015-04-30 2016-12-07 华为技术有限公司 一种移动终端的通信方法及移动终端
KR20170140344A (ko) * 2015-04-30 2017-12-20 후아웨이 테크놀러지 컴퍼니 리미티드 이동 단말을 위한 통신 방법 및 이동 단말
EP3282735A4 (fr) * 2015-04-30 2018-04-25 Huawei Technologies Co. Ltd. Procédé de communication de terminal mobile, et terminal mobile
KR101940164B1 (ko) * 2015-04-30 2019-01-18 후아웨이 테크놀러지 컴퍼니 리미티드 이동 단말을 위한 통신 방법 및 이동 단말
US10638311B2 (en) 2015-04-30 2020-04-28 Huawei Technologies Co., Ltd. Communication method for mobile terminal and mobile terminal
CN106211144B (zh) * 2015-04-30 2020-06-16 华为技术有限公司 一种移动终端的通信方法及移动终端
EP3418934A4 (fr) * 2016-03-15 2018-12-26 Huawei Technologies Co., Ltd. Procédé, dispositif et équipement utilisateur de saisie de données
US10831905B2 (en) 2016-03-15 2020-11-10 Huawei Technologies Co., Ltd. Data input method and apparatus and user equipment
US11574064B2 (en) 2016-03-15 2023-02-07 Huawei Technologies Co., Ltd. Data input method and apparatus and user equipment
CN112005237A (zh) * 2018-04-30 2020-11-27 谷歌有限责任公司 安全区中的处理器与处理加速器之间的安全协作
CN112005237B (zh) * 2018-04-30 2024-04-30 谷歌有限责任公司 安全区中的处理器与处理加速器之间的安全协作

Also Published As

Publication number Publication date
CA2902294A1 (fr) 2014-09-18
EP2973201A1 (fr) 2016-01-20

Similar Documents

Publication Publication Date Title
US20140281560A1 (en) Secure zone on a virtual machine for digital communications
US20140282543A1 (en) Secure zone on a virutal machine for digital communications
CA2918596C (fr) Serveur securise sur un systeme avec des machines virtuelles
US9698988B2 (en) Management control method, apparatus, and system for virtual machine
CN105745661B (zh) 对权限管理的内容的基于策略的受信任的检测
JP2022505355A (ja) 周辺デバイス
EP2672673B1 (fr) Appareil et méthode pour traitement de données sécurisé
US20190342293A1 (en) Secure Zone for Secure Purchases
WO2019185125A1 (fr) Gestion de licences d'instances d'un environnement d'exécution de confiance
US11763301B2 (en) Systems, methods and apparatuses for securely storing and providing payment information
KR20200085724A (ko) 호스트 시스템과 데이터 처리 가속기 사이의 보안 통신을 제공하기 위한 방법 및 시스템
TW201349009A (zh) 用於數位通信之安全區
US11704442B2 (en) Instance handling of a trusted execution environment
US10771249B2 (en) Apparatus and method for providing secure execution environment for mobile cloud
EP2973201A1 (fr) Zone sécurisée sur machine virtuelle pour communications numériques
Brasser et al. Softer Smartcards: Usable Cryptographic Tokens with Secure Execution
Mohanty et al. Media data protection during execution on mobile platforms–A review
JP6741236B2 (ja) 情報処理装置
US20240037217A1 (en) Digital content management through on-die cryptography and remote attestation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14722732

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2014722732

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014722732

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2902294

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE