CN110059489B

CN110059489B - Secure electronic device

Info

Publication number: CN110059489B
Application number: CN201810054837.2A
Authority: CN
Inventors: 林继周; 刘皓治; 和正平
Original assignee: Sunasic Technologies Inc
Current assignee: Sunasic Technologies Inc
Priority date: 2018-01-19
Filing date: 2018-01-19
Publication date: 2021-08-17
Anticipated expiration: 2038-01-19
Also published as: CN110059489A

Abstract

The invention discloses a secure electronic device. The secure electronic device comprises a first core processing unit, a secure boot read-only memory, a first persistent memory, a first volatile memory and a first communication interface. A new architecture based on the secure electronic device and with built-in security mechanisms can maintain intellectual property rights of developers and further improve the security of the secure electronic device. Thus, more developers can launch their programs or services without being stolen or tampered with by an unauthorized party.

Description

Secure electronic device

Technical Field

The present invention relates to a secure electronic device, and more particularly, to a secure electronic device implementing a secure zone.

Background

Mobile devices are widely used in our daily lives, and the internet of things is rapidly developing, which has increased the demand for security. To accommodate these security requirements, many security methods have been developed. The Trusted Platform Module (TPM) is an implementation of a secure cryptoprocessor, introducing the concept of Trusted computing on the x86 Platform. Similar to how a trusted platform module makes a personal computer "trustworthy", TrustZone is a system on a chip (SoC) and CPU system approach that targets security to establish trust in an ARM-based platform.

U.S. patent No. 7,305,534 discloses a data execution apparatus and method for controlling access to memory to partition the data execution apparatus into a secure domain and a non-secure domain. U.S. Pat. No. 7,966,466 discloses a memory access control circuit for controlling access to a memory address space. The ARM TrustZone technology applies the methods to divide the SoC into a security domain and a non-security domain.

However, these approaches do not provide content protection within the secure domain, which is required by different trusted developers working cooperatively within the secure domain. Content protection may be provided in a non-secure domain using virtualization technology for high-end socs, but it is not suitable for low-cost products due to limited computational power and resources, such as memory size.

When two or more different developers are to process security material within the security domain, they all need to have access to the security domain to store their code separately. In this case, trusted developers have to collaborate in the security domain, but this does not mean that they have to relinquish protection of intellectual property. Therefore, there is a need for a new architecture based on built-in security devices to provide content protection for developers against executable code (intellectual property).

Disclosure of Invention

This paragraph of text extraction and compilation has certain features of the present invention. Other features will be disclosed in subsequent paragraphs. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the appended claims.

The invention discloses a secure electronic device. The secure electronic device is configured to implement a secure environment having a plurality of secure executable program code, the secure executable program code having content protection functionality. The secure electronic device includes: the first core processing unit is used for executing an authentication process, managing a security executable program code transmission process, and executing the security executable program code and a general purpose application program, wherein the authentication process comprises bidirectional verification between the secure electronic device and a plurality of code transmission devices. The first core processing unit is configurable into two isolated environments: a secure environment that uses hardware or time-slicing methods and a normal environment such that any instructions and data in the secure environment cannot be directly accessed by the normal environment or external devices. The secure boot read-only memory is connected to the first core processing unit and has a first private key stored therein, and the first private key is used by the code transmission device to verify the secure electronic device. A first persistent memory connected to the first core processing unit, wherein the first persistent memory is configurable as two isolated portions: the first protection permanent memory is used for storing a first safety executable program code item and a second safety executable program code item. And a general-purpose persistent memory for storing general-purpose application data associated with a general-purpose application, wherein the first secure executable code entry includes the first secure executable code and a second public key of a second asymmetric password. The second secure executable program code entry includes a second secure executable program code and a third public key of a third asymmetric password, the second and third public keys being used by the secure electronic device to authenticate the code transfer devices. At least a portion of the first protected persistent memory storing the secure executable program code is configured into an execution-only memory (XOM). A first volatile memory coupled to the first core processing unit, wherein the first volatile memory is configurable as two isolated portions: a first protected volatile memory for temporarily storing secure data for the core processing unit. And a general-purpose volatile memory for temporarily storing data associated with a general-purpose application for the core processing unit. And a first communication interface for communicating with the code transmission devices, wherein if the authentication process is successful, the data exchanged between the secure electronic device and the code transmission devices is encrypted/decrypted using a symmetric session key. The first public key and the first private key stored in the code transmission devices are a pair of keys of a first asymmetric password. The second public key and a second private key stored in the first code transmission device are a pair of keys of the second asymmetric cipher. The third public key and a third private key stored in the second code transmission device are a pair of keys of the third asymmetric cipher.

According to the invention, the code transmission device comprises: the second core processing unit is used for executing an authentication process and managing the transmission process of the security executable program code. A second protection permanent memory for storing one of the first public key and private key of the first asymmetric cipher, at least a portion of the second protection permanent memory storing the first public key and private key being protected by a protection mechanism to prevent the stored code and data from being directly accessed by external institutions. A second protected volatile memory for temporarily storing data for the second core processing unit. And a second communication interface for communicating with the secure electronic device.

In one embodiment, the second protected persistent memory further stores a copy of the secure executable program code. At least a portion of a second protected persistent memory storing the secure executable code is protected by the protection mechanism to prevent direct access to the stored code and data by external entities.

According to the present invention, the code transmission apparatus may further include: a file encryption key stored in the second protected persistent memory. And a removable external memory unit to store a copy of the secure executable program codes, wherein the secure executable program codes are encrypted using the file encryption key.

The authentication process and the encryption/decryption system used in the secure executable code transfer process are hardware circuits built into the first core processing unit or instructions stored in the secure boot ROM that are executed by the first core processing unit after a boot sequence.

In one embodiment, the first asymmetric key may be ECC (elastic-current Cryptography) or RSA, the second asymmetric key may be ECC or RSA, the secure electronic device may be SoC (system on chip), and the code transmission device may be SoC.

The entitlement management system may include an entitlement control file that stores management information. The management information may include license times and/or configuration data for each installation.

Drawings

FIG. 1 is a block diagram of a secure electronic device and a code transmission device according to a first embodiment of the present invention;

FIG. 2 is a block diagram of another code transmission apparatus according to a second embodiment of the present invention;

FIG. 3 is a block diagram of another secure electronic device and three code transmitting devices according to a third embodiment of the present invention;

FIG. 4 is an exemplary process flow of the present invention illustrating communication between a secure electronic device and a code transfer device;

FIG. 5 illustrates an exemplary two-way authentication process according to the present invention;

fig. 6 illustrates another exemplary two-way authentication process according to the present invention.

Description of the reference numerals

100: secure electronic device

110: a first core processing unit

111: first secure environment

112: general environment

120: secure boot read-only memory

130: first permanent memory

131: first protection permanent memory

1311: first secure executable program code entry

1312: second secure executable program code entry

132: general purpose persistent memory

140: first volatile memory

141: first protection volatile memory

142: general purpose volatile memory

150: first communication interface

200: first code transmission apparatus

210: second core processing unit

211: secure environment

230: second protection permanent memory

231: first secure executable program code

240: second protection volatile memory

245: second communication interface

270: external memory unit

271: encrypted secure executable program code

300: second code transmission apparatus

310: a third core processing unit

311: secure environment

330: third protection permanent memory

331: second secure executable program code

340: third protection impermance

345: third communication interface

400: third code transmission apparatus

430: second protection permanent memory

901: file encryption key

910: first private key

911: first public key

920: second private key

921: second public key

930: third private key

931: third public key

940: fourth private key

941: fourth public key

Detailed Description

The present invention will be more specifically described with reference to the following embodiments.

Referring to fig. 1, a block diagram of a secure electronic device 100 and first and second

code transmission devices

200 and 300 according to the present invention is shown. The secure electronic device 100 includes a first core processing unit 110, a secure boot rom 120, a first persistent memory 130, a first volatile memory 140, and a first communication interface 150. The secure boot rom 120, the first persistent memory 130, the first volatile memory 140, and the first communication interface 150 are connected to the first core processing unit 110, and they may form a system on chip (SoC) to improve the security of the secure electronic device 100. The secure electronic device 100 is used to implement a secure execution environment that is isolated from the normal execution environment. Instructions relating to sensitive data, such as personal information or security functions, are executed in a secure execution environment to prevent theft of secrets. To accomplish the isolation of the two environments, the first core processing unit 110, the first persistent memory 130, and the first volatile memory 140 need to be configured into two isolated portions. The first core processing unit 110 is divided into a first secure environment 111 and a normal environment 112. The first core processing unit 110 utilizes hardware or time slicing so that any instructions and data in the first secure environment 111 cannot be directly accessed by the normal environment 112 or external devices. The first core processing unit 110 also performs authentication procedures, manages secure executable code transfer procedures, and executes secure executable code in the first secure environment 111 and application programs in the normal environment 112. The authentication procedure involves a two-way authentication between the secure electronic device 100 and the first code transmitting device 200 (or the second code transmitting device 300, depending on which device the secure electronic device 100 is communicating with). A first persistent memory 130, such as a flash memory, is configured to a first protected persistent memory 131 and a general purpose persistent memory 132. Sensitive data and instructions related to the sensitive data are stored in the first protected persistent memory 131, and other data and/or instructions, such as general purpose applications, are stored in the general purpose persistent memory 132. Instructions for sensitive data are stored in executable code and referred to hereafter as secure executable code. At least a first 1311 and a second 1312 security executable are stored in the first protected persistent memory 131. The first secure executable code entry 1311 contains the first secure executable code 231 and a second public key 921 of a second asymmetric cipher. The second secure executable code entry 1312 includes the second secure executable code 331 and a third public key 931 of a third asymmetric cipher. Asymmetric cryptography is used for two-way authentication and will be described later in the specification. The first volatile memory 140, such as SRAM, is configured as a first protected volatile memory 141 and a general-purpose volatile memory 142 for temporarily storing security data and storing data for the first core processing unit 100 regarding general-purpose applications, respectively. The secure boot rom 120 stores a secure boot instruction and a first private key 910. The secure boot rom 120 may be a mask rom embedded in a wafer or a write-protected flash memory. First private key 910 is provided by the device manufacturer and used by other devices, such as a single chip programmer or burner, to authenticate secure electronic device 100. The first communication interface 150 is used for the secure electronic apparatus 100 to communicate with other apparatuses. The secure electronic device 100 may be an SoC based on the TrustZone technology of ARM corporation with content protection.

The secure executable program code may be provided by a developer of a non-wafer manufacturer. The first code transmitting device 200 of fig. 1 is used for the developer to transmit the secure executable program code to the secure electronic device 100. Secure electronic device 100 may not be needed if the developer transmits a general-purpose application. The first code transmitting device 200 comprises a second core processing unit 210, a second protection nonvolatile memory 230, a second protection nonvolatile memory 240, and a second communication interface 245. The second protection nonvolatile memory 230, the second protection volatile memory 240, and the second communication interface 245 are connected to the second core processing unit 210, which may form a SoC to improve the security of the first code transmitting apparatus 200. The first code transmitting device 200 is used to implement a secure execution environment: all communications between the first code transmitting device 200 and other devices are supervised by the authentication process. The second core processing unit 210 includes a secure environment 211, and the authentication process and the secure executable code transmission process are executed in the secure environment 211. The second protected persistent memory 230 has a first public key 911, a second private key 920, and a first security executable 231 stored therein. At least a portion of the second persistent storage 230 storing the first public key 911, the second private key 920, and the first security executable 231 is protected by a protection mechanism to prevent the stored code and data from being directly accessed by any external entity. The protection mechanism may be "FlashLock TM with AES" as proposed by Sergei Skorobatov and Christopher Woods instituted in Breaktrough Silicon Scanning discovery background in Military Chip, Cryptographic Hardware and Embedded Systems- -CHES 2012: p 23-40. The second protection volatile memory 240 is used for temporarily storing data for the second core processing unit 210. The second communication interface 245 is used for the first code transmitting device 200 to communicate with other devices. The second code transmitting device 300 is a device that recognizes the first code transmitting device 220, and the second code transmitting device 300 has a third core processing unit 310, a third protected persistent memory 330, a third protected volatile memory 340, and a third communication interface 345. The third core processing unit 310 includes a secure environment 311, and the instructions of the authentication process and the secure executable code transfer process are executed in the secure environment 311. The second private key 920 and the first secure executable code 231 in the first code transfer device 200 are replaced by the third private key 930 and the second secure executable code 331, respectively. The second code transmitting device 300 is used for another developer to transmit the second secure executable code to the secure electronic device 100.

Please refer to fig. 2. Fig. 2 is another embodiment of a first code transmitting device 200. The difference between this embodiment and the previous embodiment is that the secure executable code is not stored in the second protected persistent memory 230, but is encrypted using the file encryption key 901 and can be stored as an encrypted file in the removable external memory unit 270. The encrypted file is shown as encrypted secure executable code 271 in FIG. 2. The file encryption key 901 stored in the second protected persistent memory 230 is used to decode the encrypted secure executable code 271. The removable external memory unit 270 may be a Secure Digital memory card (SD card) that is connected to the second core processing unit 210 using a Secure Digital Input Output (SDIO) interface. The file Encryption key 901 may be a key for a symmetric key cipher, such as the Advance Encryption Standard (AES).

In this section, the architecture of the content protection functionality provided by the secure electronic device 100 will be described in detail below. Basically, the content protection function architecture will be divided into three parts: secure electronic device 100, code transmission device, and communications therebetween. In the secure electronic device 100, two major elements together create a content protection function. The first element is a secure execution environment isolated from the normal execution environment causing the secure execution environment contents to be protected, and the second element is a portion of the first protected persistent memory 131 storing secure executable program code configured to an execution only memory (XOM). Us patent 7,895,404 discloses a method for providing one or more protected areas of memory with exclusive access rights. Using XOM may only allow instruction fetching and not read and write accesses. Thus, storing secure executable program code into the execution-only memory may prevent another developer from reading the code, the secure executable program code being provided by the developer. The secure execution environment provides a first level of content protection between the secure execution environment and the normal execution environment, and the XOM provides a second level of content protection between each secure executable code in the secure execution environment. Sensitive material that cannot be accessed by general-purpose applications in the general environment 112 can now be shared between different secure executable code from different developers without compromising the privacy of each secure executable code. The use of XOM may also provide additional tamper resistance for the secure electronic device 100. In the code transfer device 200, the secure executable code is protected by the secure execution environment 211 with a file encryption key 901 or a protection mechanism, such as flashlock.

Regarding the communication between the secure electronic device 100 and the code transmission device 200, the two-way authentication is used for the two devices to authenticate each other. Please refer to fig. 3, which is a block diagram of a secure electronic device and three code transmitting devices according to a third embodiment of the present invention. Other elements have no significant relation to bi-directional authentication and are ignored here. The first public key 911 and the first private key 910 are a pair of keys of a first asymmetric cipher, and are used by the first code transmission apparatus 200 to authenticate the secure electronic apparatus 100. The second public key 921 and the second private key 920 are a pair of keys of a second asymmetric cipher, and are used for the secure electronic device 100 to authenticate the first code transmission device 200. The third public key 931 and the third private key 930 are a pair of keys of a third asymmetric cipher for the secure electronic device 100 to authenticate the second code transmitting device 300. The fourth public key 941 and the fourth private key 940 are a pair of keys of a fourth asymmetric cipher, and are used for the secure electronic device 100 to authenticate the third code transmission device 400. Like other code transfer devices, fourth private key 940 and first public key 911 are stored in fourth protected persistent memory 430 of third code transfer device 400. Once the secure executable program code entry is present in the secure electronic device 100, the secure executable program code can be read and/or modified if the two-way authentication is successful. In the case where the secure executable program code is stored in the removable external memory unit 270, the secure executable program code is further protected by the file encryption key 901. Thus, the content (i.e. the secure executable program code) is well protected under this framework. If no secure executable program code entry exists in the secure electronic device 100, the secure executable program code may be written to a predetermined memory area upon successful authentication of the first secure electronic device 100 (by the code transfer device 200).

Referring to fig. 4, an exemplary process for communicating between the secure electronic device 100 and the code transmitting devices is shown. The exemplary process includes the authentication process and the secure executable code transfer process described above. In this example, a new version of the secure executable code will be written to the corresponding memory region in place of the old version. The bi-directional authentication process determines which secure executable code is to be replaced. If the secure electronic device 100 is connected to the second code transmitting device 300, the two-way authentication will give a result: because third public key 931 and third private key 930 are a pair of keys, the second secure executable code will be modified. The entire flow starts by connecting the secure electronic apparatus 100 to the code transmission apparatus 200 using the communication interface (S01). The process includes determining whether the bidirectional authentication is successful (S02). If the two-way authentication is successful, both devices will recognize that each other is a valid device. Before transferring the secure executable program code, the available memory size and location of the first protected persistent memory 113 is checked (S03). In a simple manner, the secure executable code has a predetermined code size and location in the first protected persistent memory 113, and there may be a table or list in the first protected persistent memory 113 for storing information on memory usage. If the result of step S03 is yes, then the portion of the first protected persistent memory 113 storing the associated safe executable program code is configured to disable the execution-only property (S04), i.e., become readable and writable. The new secure executable program code will be transferred to the secure electronic device 100 and written to the memory area (S05). In the last step, the memory area will be configured to XOM again to protect the secure executable program code (S06). When step S02 or S03 fails, the entire flow stops and a message of authentication failure is returned.

Referring to fig. 5, an exemplary flow of two-way authentication is shown. The two-way authentication process utilizes a public key cryptosystem, such as RSA or Elliptic-secure cryptography (ECC), to establish a trusted communication. A first authentication is used for the code transmission device 200 to authenticate the secure electronic device 100 and a second authentication is used for the secure electronic device 100 to authenticate the code transmission device 200. First, the secure electronic apparatus 100 generates a first message (S11), signs the first message using the first private key 910 (S12), and then sends the signed message to the code transmitting apparatus 200 (S13). When the code transmitting apparatus 200 receives the signed message, the code transmitting apparatus 200 verifies the signed message using the first public key 911 (S14). If the verification is successful, the code transmitting apparatus 200 generates a session key (S15), signs the session key (as a second message) using the second private key 920 (S16), encrypts the signed session key using the first public key 911 (S17), and then sends the encrypted and signed session key to the secure electronic apparatus 100 (S18). The secure electronic device 100 decrypts the encrypted and signed session key using the first private key 910 (S19) and verifies the session key using the second public key 921 (S20). If the authentication is successful, the secure electronic device 100 obtains a session key (S21) and encrypts the transmission flow using the session key (S22). If multiple secure executable program code entries exist in the secure electronic device 100, each public key in the secure executable program code entry will be used in step S20 to find the corresponding secure executable program code entry.

Referring to fig. 6, another exemplary flow of two-way authentication is shown. In this example, the session key is generated using the Diffie-Hellm key exchange protocol, which is a common way of ECC key exchange. Eliptic-secure Diffie-hellm (ecdh) is an anonymous key agreement that allows two parties, each with an Elliptic curve public-private key pair, to establish a shared secret through an insecure channel. Therefore, the encryption step S17 and the decryption step S19 are not required in this example. The process comprises the following steps: the secure electronic apparatus 100 generates a first message (S31), signs the first message using the first private key 910 (S32), and issues the signed message to the code transmitting apparatus 200 (S33). When the code transmitting apparatus 200 receives the signed first message, the code transmitting apparatus 200 verifies the signed first message using the first public key 911 (S34). If the verification is successful, the code transmitting apparatus 200 generates a shared secret using the first message (S35) and the second message (S36), signs the second message using the second private key 920 (S37), and sends the signed second message to the secure electronic apparatus 100 (S38). The secure electronic apparatus 100 verifies the signed second message using the second public key 921 (S39). If the authentication is successful, the secure electronic apparatus 100 generates a shared secret using the second communication (S40) and encrypts the transmission flow using the shared secret as a session key (S41). The first message and the second message include information for generating a shared secret for an ECDH exchange protocol.

The removable external memory unit 270 may further include an authorization management system. The authorization management system includes an encrypted admission control file and instructions for interacting with a secure executable program code transmission flow. The encrypted license control file may be encrypted using the file encryption key 901 or another symmetric key (not shown). The license control file stores management information such as the number of licenses (the number of copies allowed), configuration data per installation, and the like. In one embodiment, the number of permissions is decremented by a factor each time the secure executable code transfer process is completed. The number of licenses can be updated by the developer. In another embodiment, the secure executable code may have different configurations, each configuration having a different amount of deduction. For example, a full function configuration of the secure executable code may merit 10 points, and a limited function configuration of the secure executable code may merit 7 points. Then, the number of permissions may be implemented in the form of quotas or points. The number of permissions is decremented in accordance with the completion of each copy. For example, if the limited functionality configuration of the secure executable code is transmitted to secure electronic device 100, the number of permissions is reduced by 7 points.

The features of the above-described embodiments may be arbitrarily combined, and for the sake of clarity of description, all possible combinations of the features in the above-described embodiments are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the features.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A secure electronic device, comprising:

a first core processing unit for performing an authentication procedure, managing a security executable code transfer procedure, and executing a security executable code and a general purpose application, wherein the authentication procedure includes a two-way authentication between the secure electronic device and a plurality of code transfer devices; the first core processing unit is configurable into two isolated environments: the method comprises the steps that a safe environment and a common environment are formed by using a hardware cutting or time cutting method, so that any instruction and data in the safe environment cannot be directly accessed by the common environment or external equipment; the secure boot read-only memory is connected to the first core processing unit and has a first private key stored therein, and the first private key is used by the code transmission equipment for verifying the secure electronic equipment;

a first persistent memory connected to the first core processing unit, wherein the first persistent memory is configurable as two isolated portions:

a first secure persistent Memory, at least a portion of the first secure persistent Memory configured as an execution-Only-Memory (XOM) to store the secure executable code and first and second secure executable code entries, wherein the first secure executable code entry includes a second public key of the first and second asymmetric passwords; the second secure executable program code entry includes a second secure executable program code and a third public key of a third asymmetric password, the second and third public keys being used by the secure electronic device to authenticate the code transfer device; and

a general purpose persistent memory for storing general purpose applications and general purpose related application data;

a first volatile memory connected to the first core processing unit, wherein the first volatile memory is configurable into two isolated portions:

a first protected volatile memory for temporarily storing secure data for the first core processing unit; and

a general-purpose volatile memory for temporarily storing data associated with a general-purpose application for the first core processing unit; and

a first communication interface for communicating with the code transmission device, wherein if the authentication procedure is successful, data exchanged between the secure electronic device and the code transmission device is encrypted/decrypted using a symmetric session key,

wherein the first public key and the first private key stored in the code transmission device are a pair of keys of a first asymmetric cipher; the second public key and a second private key stored in the first code transmission equipment are a pair of keys of the second asymmetric password; the third public key and a third private key stored in the second code transmission device are a pair of keys of the third asymmetric cipher.

2. The secure electronic device of claim 1, wherein the code transfer device comprises:

a second core processing unit for executing an authentication process and managing the security executable program code transmission process;

a second protected persistent memory for storing the first public key and the second private key of the first asymmetric cipher, wherein at least a portion of the second protected persistent memory storing the first public key and the second private key is protected by a protection mechanism to prevent the stored code and data from being directly accessed by an external entity;

a second protected volatile memory for temporarily storing data for said second core processing unit; and

and the second communication interface is used for communicating with the safety electronic equipment.

3. A secure electronic device as recited in claim 2, wherein the second protected persistent memory further stores a copy of the secure executable program code; at least a portion of a second protected persistent memory storing the secure executable code is protected by the protection mechanism to prevent direct access to the stored code and data by an external entity.

4. The secure electronic device of claim 2, wherein the code transfer device further comprises:

a file encryption key stored in the second protected persistent memory; and

a removable external memory unit to store a copy of the secure executable program code, wherein the secure executable program code is encrypted using the file encryption key.

5. The secure electronic device of claim 1, wherein the encryption/decryption system used in the authentication process and the secure executable code transfer process is a hardware circuit built into the first core processing unit or an instruction stored in the secure boot ROM to be executed by the first core processing unit after a boot sequence.

6. The secure electronic device of claim 1, wherein the first asymmetric password is ECC (eliptic-current Cryptography) or RSA.

7. The secure electronic device of claim 1, wherein the second asymmetric password is an ECC or an RSA.

8. A secure electronic device according to claim 1, wherein the secure electronic device is a system-on-a-chip.

9. A secure electronic device according to claim 1, wherein the code transfer device is a system-on-a-chip.

10. The secure electronic device of claim 2, wherein the code transfer apparatus further comprises an authorization management system, the authorization management system comprising an admission control file storing management information.

11. A secure electronic device according to claim 10, wherein the management information includes a number of licenses and/or configuration data for each installation.