US20150347758A1 - Methods and systems for securely transferring embedded code and/or data designed for a device to a customer - Google Patents

Methods and systems for securely transferring embedded code and/or data designed for a device to a customer Download PDF

Info

Publication number
US20150347758A1
US20150347758A1 US14/799,765 US201514799765A US2015347758A1 US 20150347758 A1 US20150347758 A1 US 20150347758A1 US 201514799765 A US201514799765 A US 201514799765A US 2015347758 A1 US2015347758 A1 US 2015347758A1
Authority
US
United States
Prior art keywords
encryption key
embedded code
data
encrypted
decrypted
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US14/799,765
Inventor
Min Wei Ang
Gerd Dirscherl
Arno Rabenstein
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Original Assignee
Infineon 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 Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to US14/799,765 priority Critical patent/US20150347758A1/en
Publication of US20150347758A1 publication Critical patent/US20150347758A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1408Protection against unauthorised use of memory or access to memory by using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034Test or assess a computer or a system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107File encryption

Definitions

  • the invention relates to methods and systems for securely transferring embedded code and/or data to a customer, in particular to methods and systems for securely transferring embedded code, data files and/or program files designed for a device to a customer in order to prevent the embedded code, data files and/or program files from being used on unauthorized devices.
  • Manufacturers of various devices such as semiconductor manufacturers, for example, sell their devices, such as integrated circuit components, for example, to different customers.
  • Specialized suppliers provide embedded code or data for the respective devices to configure and/or customize the respective devices according to the demands and requests of the customers.
  • the customers may then program the devices bought from the manufacturer at their location with the embedded code or data obtained from the suppliers.
  • This transfer of embedded code or data involves a number of piracy risks.
  • the embedded code or data could leak through grey channels to a pirate production plant which could then program clone hardware using available loader tools from the Internet.
  • the customer could also try to pay less license fees to the software producer by under-declaring the number of produced devices containing the embedded code or data since this information is transparent to the software producer.
  • One approach for protecting embedded code or data is to provide the devices to be sold with unique identification numbers so that the software producers can include trap routines in the embedded code. These trap routines freeze the operation of the device if the embedded code is used illegally. However, besides increasing the code size, this scheme can still be reasonably hacked by replacing the trap routines with dummy code.
  • a method for securely transferring embedded code and/or data designed by a supplier for a device produced by a manufacturer to a customer comprises storing a first encryption key in a memory of a device to be delivered to a customer, encrypting embedded code and/or data designed for the device using a second encryption key, and encrypting the second encryption key using the first encryption key.
  • a system for securely transferring embedded code and/or data designed for a device to a customer comprises a secure boot loader and a first encryption key stored in a memory of a device.
  • the secure boot loader is configured to receive a second encryption key encrypted with the first encryption key, receive embedded code and/or data designed for the device and encrypted with the second encryption key, decrypt the received encrypted second encryption key using the first encryption key stored in the device, and decrypt the embedded code and/or data using the decrypted second encryption key.
  • FIG. 1 shows a simplified schematic diagram of an example environment wherein a system according to an embodiment of the invention may be implemented.
  • FIG. 2 shows a simplified schematic diagram of a further example environment wherein a system according to a further embodiment of the invention may be implemented.
  • FIG. 3 shows an example method according to an embodiment of the invention.
  • FIG. 1 shows a simplified schematic diagram of an example environment wherein a system according to an embodiment of the invention may be implemented.
  • a device 17 is produced by a manufacturer, e.g. a semiconductor manufacturer, at the manufacturer's location, e.g. a semiconductor plant 11 , sold to a customer and delivered to the customer location 13 .
  • a supplier which can be a software producer 12 in this example, provides the customer with an embedded code or data designed for the device 17 bought by the customer. The customer will then program the device 17 bought from the manufacturer at their location 13 with the embedded code or data provided by the supplier or software producer 12 in this example.
  • the customer can be a distributor which customizes the devices, a company which integrates the devices in their own products, or a user, for example.
  • This transfer of embedded code or data involves a number of piracy risks.
  • the embedded code or data could leak through grey channels to a pirate production plant which could then program clone hardware using available loader tools from the Internet.
  • the customer could also try to pay less license fees to the supplier by under-declaring the number of produced devices containing the embedded code or data since this information is transparent to the supplier.
  • the (semiconductor) manufacturer provides each device with an encryption key which may be stored in a memory, such as a flash memory, of the device 17 .
  • a memory such as a flash memory
  • the supplier or, in this example, software producer 12 provides the embedded code or data designed for the device 17 to the customer in encrypted form, i.e. encrypted with the encryption key.
  • the (semiconductor) manufacturer may perform the encryption of the embedded code or data with the encryption key.
  • the manufacturer may provide the software producer with an identification (ID) number allocated to the respective device to enable the software producer to generate the encryption key based on the ID number using a master key or a database.
  • ID identification
  • the thus generated encryption key is used to encrypt the embedded code or data without revealing the encryption key itself.
  • the software producer may generate the encryption key as an intermediate result, this intermediate result is a direct input to the encryption of the embedded code or data and is otherwise not accessible.
  • the software producer does not get knowledge of the encryption key as this key is an intermediate result within a closed process which is protected from external access.
  • the software producer 12 may then transmit the encrypted code/data to the customer location 13 .
  • the encrypted embedded code/data is received and fed to the secure boot loader 19 of the device 17 to program the device 17 .
  • the secure boot loader 19 decrypts the encrypted embedded code/data and stores the decrypted embedded code/data in a memory, in particular a flash memory, of the device 17 .
  • FIG. 2 shows a simplified schematic diagram of a further example environment wherein a system according to a further embodiment of the invention may be implemented.
  • a device 27 is produced by a manufacturer, e.g. a semiconductor manufacturer, at the manufacturers location, e.g. a semiconductor plant 11 , sold to a customer and delivered to the customer location 13 .
  • a supplier which can be a software producer 12 in this example, provides the customer with an embedded code or data designed for the device 27 bought by the customer. The customer will then program the device 27 bought from the manufacturer at their location 13 with the embedded code or data provided by the supplier or software producer 12 in this example.
  • the customer can be a distributor which customizes the devices, a company which integrates the devices in their own products or a user, for example.
  • the (semiconductor) manufacturer provides each device with a first encryption key which may be stored in a memory, such as a flash memory, of the device 27 .
  • a memory such as a flash memory
  • the supplier or, in this example, software producer 12 provides the embedded code or data designed for the device 27 to the customer in encrypted form, in this case, encrypted with a second, different encryption key.
  • the second encryption key for encrypting the embedded code or data is also transmitted to the customer in encrypted form, wherein the second encryption key is encrypted with the first encryption key.
  • the manufacturer may perform the encryption of the second encryption key with the first encryption key and provide the software producer with the encrypted second encryption key.
  • the semiconductor manufacturer may provide the software producer 12 with an identification (ID) number allocated to the respective device to enable the software producer 12 to generate the first encryption key based on the ID number using a master key or a database.
  • ID identification
  • the reproduced first encryption key is used to encrypt the second encryption key without revealing the first encryption key itself:
  • the software producer 12 may generate the first encryption key as an intermediate result, this intermediate result is directly input to the encryption process for the second encryption key and is otherwise not accessible.
  • the software producer does not get knowledge of the first encryption key as it is an intermediate result within a closed process which is protected from external access.
  • the software producer 12 then transmits both the encrypted embedded code/data and the encrypted second encryption key to the the customer location.
  • the encrypted embedded code/data and the encrypted second encryption key are received and fed to the secure boot loader 29 of the device 27 .
  • the secure boot loader 29 decrypts the encrypted second encryption key using the first encryption key stored within the device 27 , decrypts the embedded code or data using the decrypted second encryption key and stores the decrypted embedded code/data in a memory, e.g. a flash memory, of the device 27 .
  • the embedded code or data can then be used for programming the device 27 .
  • received encrypted data may be downloaded first into a random access memory (RAM) of the device 17 and 27 , respectively, using the secure boot loader 19 and 29 , respectively, which may be part of the firmware of the device 17 and 27 , respectively.
  • the secure boot loader 19 and 29 may be in the form of a flash memory as well. Based on the type of data, the secure boot loader 19 and 29 , respectively, may then perform the decryption and programming to targeted locations on a flash memory.
  • the specific number of devices authorized to run or use the embedded code or data is controllable and may also be provided to the software producers as a value-added service.
  • the number of devices which can use the encrypted embedded code or data is limited.
  • the group of devices which are allocated a common encryption key is arbitrary. For example, one unique encryption key may be allocated to one batch of devices or to all devices provided to a certain customer. Even a unique encryption key could be allocated to each single device which would, however, involve rather high administrative effort.
  • the software producer obtains a rough estimation of distributed embedded codes/data. Given that a separate second encryption key is generated for each first encryption key, the total number of distributed codes/data may be obtained by multiplying the number of generated second encryption keys by the number of devices which are furnished with a common first encryption key.
  • the task of device variant configuration may be delegated to the customer by providing the customer with an encrypted file which performs the desired configuration when executed.
  • special hardware features may be enabled or disabled, such as access to memory regions, etc.
  • a specific set of hardware features required for a certain embedded code may also be activated by such a file transmitted in encrypted form.
  • an encrypted peripheral activation code (PAC) may be transmitted to the customer so that the customer can tailor a feature set according to the application's needs and unlock dedicated peripherals.
  • PAC peripheral activation code
  • a customer may also be offered the possibility to upgrade a device bought in the past by purchasing the appropriate encrypted file which activates the desired additional features when executed.
  • an update of the second encryption key may be facilitated by securely transferring the new second encryption key in encrypted form, encrypted with the first encryption key, for example.
  • encryption may be based on symmetric encryption algorithms such as AES (Advanced Encryption Standard), DES (Data Encryption Standard), Triple-DES, Blowfish, Serpent, Twofish, etc., or public-key cryptography also called asymmetric key cryptography which uses asymmetric key algorithms (e.g. RSA).
  • AES Advanced Encryption Standard
  • DES Data Encryption Standard
  • Triple-DES Triple-DES
  • Blowfish Blowfish
  • Serpent Twofish
  • Twofish etc.
  • public-key cryptography also called asymmetric key cryptography which uses asymmetric key algorithms (e.g. RSA).
  • AES Advanced Encryption Standard
  • DES Data Encryption Standard
  • Triple-DES Triple-DES
  • Blowfish Blowfish
  • Serpent Serpent
  • Twofish etc.
  • public-key cryptography also called asymmetric key cryptography which uses asymmetric key algorithms (e.g. RSA).
  • AES Advanced Encryption Standard
  • a hybrid cryptosystem may also be used.
  • the hybrid cryptosystem is itself a public-key system, which encapsulates a symmetric-key scheme.
  • the bulk of the work in encryption/decryption could be done by the more efficient symmetric-key scheme, while the inefficient public-key scheme is only used to encrypt/decrypt a short session key value.
  • the efficient implementation of the symmetric-key decryption may be used for flash programming.
  • the first encryption key used in embodiments described above may be an asymmetric key and the second encryption key may be a symmetric key, for example.
  • FIG. 3 shows an example method according to an embodiment of the invention, in particular, a method for securely transferring embedded code or data designed by a supplier for a device produced by a manufacturer to a customer.
  • the example method comprises storing a first encryption key in a memory of a device to be delivered to a customer at 302 , and encrypting embedded code or data designed for the device using a second encryption key at 304 .
  • the method further comprises encrypting the second encryption key using the first encryption key at 306 , sending the encrypted embedded code or data and the encrypted second encryption key to a customer location at 308 , and receiving the encrypted embedded code or data and the encrypted second encryption key at the customer location at 310 .
  • the method comprises decrypting the received encrypted second encryption key at the customer location using the first encryption key stored in the device at 312 , and decrypting the received encrypted embedded code or data at the customer location using the decrypted second encryption key at 314 . It is, however, to be appreciated that the order of steps depicted in FIG. 3 and described above is only one example sequence and many other sequences of actions are also possible.

Abstract

The invention relates to methods and systems for securely transferring embedded code or data to a customer, in particular to methods and systems for securely transferring embedded code, data files or program files designed for a device to a customer in order to prevent the embedded code, data files or program files from being used on unauthorized devices.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • This patent application is a continuation patent application claiming priority to U.S. patent application Ser. No. 13/687,066 filed Nov. 28, 2012 in the name of Min Wei Ang, et al. entitled “Methods and Systems for Securely Transferring Embedded Code and/or Data Designed for a Device to a Customer” and is hereby incorporated in its entirety.
  • FIELD
  • The invention relates to methods and systems for securely transferring embedded code and/or data to a customer, in particular to methods and systems for securely transferring embedded code, data files and/or program files designed for a device to a customer in order to prevent the embedded code, data files and/or program files from being used on unauthorized devices.
  • BACKGROUND
  • Manufacturers of various devices, such as semiconductor manufacturers, for example, sell their devices, such as integrated circuit components, for example, to different customers. Specialized suppliers provide embedded code or data for the respective devices to configure and/or customize the respective devices according to the demands and requests of the customers. The customers may then program the devices bought from the manufacturer at their location with the embedded code or data obtained from the suppliers.
  • This transfer of embedded code or data involves a number of piracy risks. The embedded code or data could leak through grey channels to a pirate production plant which could then program clone hardware using available loader tools from the Internet. The customer could also try to pay less license fees to the software producer by under-declaring the number of produced devices containing the embedded code or data since this information is transparent to the software producer.
  • One approach for protecting embedded code or data is to provide the devices to be sold with unique identification numbers so that the software producers can include trap routines in the embedded code. These trap routines freeze the operation of the device if the embedded code is used illegally. However, besides increasing the code size, this scheme can still be reasonably hacked by replacing the trap routines with dummy code.
  • Therefore, there exists a need for a method and system for securely transferring embedded code and/or data designed for a device to a customer in order to prevent the embedded code or data from being used on unauthorized devices.
  • SUMMARY
  • In accordance with an aspect of the invention, there is provided a method for securely transferring embedded code and/or data designed by a supplier for a device produced by a manufacturer to a customer. The method comprises storing a first encryption key in a memory of a device to be delivered to a customer, encrypting embedded code and/or data designed for the device using a second encryption key, and encrypting the second encryption key using the first encryption key.
  • In accordance with a further aspect of the invention, there is provided a system for securely transferring embedded code and/or data designed for a device to a customer. The system comprises a secure boot loader and a first encryption key stored in a memory of a device. The secure boot loader is configured to receive a second encryption key encrypted with the first encryption key, receive embedded code and/or data designed for the device and encrypted with the second encryption key, decrypt the received encrypted second encryption key using the first encryption key stored in the device, and decrypt the embedded code and/or data using the decrypted second encryption key.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The accompanying drawings are included to provide a further understanding of the present invention and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the present invention and together with the description serve to explain the principles of the invention. Other embodiments of the present invention and many of the intended advantages of the present invention will be readily appreciated as they become better understood by reference to the following detailed description.
  • FIG. 1 shows a simplified schematic diagram of an example environment wherein a system according to an embodiment of the invention may be implemented.
  • FIG. 2 shows a simplified schematic diagram of a further example environment wherein a system according to a further embodiment of the invention may be implemented.
  • FIG. 3 shows an example method according to an embodiment of the invention.
  • DETAILED DESCRIPTION
  • In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or other changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.
  • FIG. 1 shows a simplified schematic diagram of an example environment wherein a system according to an embodiment of the invention may be implemented. A device 17 is produced by a manufacturer, e.g. a semiconductor manufacturer, at the manufacturer's location, e.g. a semiconductor plant 11, sold to a customer and delivered to the customer location 13. In addition, a supplier which can be a software producer 12 in this example, provides the customer with an embedded code or data designed for the device 17 bought by the customer. The customer will then program the device 17 bought from the manufacturer at their location 13 with the embedded code or data provided by the supplier or software producer 12 in this example. The customer can be a distributor which customizes the devices, a company which integrates the devices in their own products, or a user, for example.
  • This transfer of embedded code or data involves a number of piracy risks. The embedded code or data could leak through grey channels to a pirate production plant which could then program clone hardware using available loader tools from the Internet. The customer could also try to pay less license fees to the supplier by under-declaring the number of produced devices containing the embedded code or data since this information is transparent to the supplier.
  • In order to protect the embedded code or data from unauthorized access and use, an encryption scheme for securely transferring the embedded code or data to a customer has been developed.
  • According to an embodiment of the invention, the (semiconductor) manufacturer provides each device with an encryption key which may be stored in a memory, such as a flash memory, of the device 17. Thus, the customer obtains an encryption key together with the ordered device 17.
  • The supplier or, in this example, software producer 12, provides the embedded code or data designed for the device 17 to the customer in encrypted form, i.e. encrypted with the encryption key.
  • However, in order to avoid revealing the encryption key to the software producer, the (semiconductor) manufacturer may perform the encryption of the embedded code or data with the encryption key.
  • Alternatively, the manufacturer may provide the software producer with an identification (ID) number allocated to the respective device to enable the software producer to generate the encryption key based on the ID number using a master key or a database. The thus generated encryption key is used to encrypt the embedded code or data without revealing the encryption key itself. Though the software producer may generate the encryption key as an intermediate result, this intermediate result is a direct input to the encryption of the embedded code or data and is otherwise not accessible. Thus, also in this case, the software producer does not get knowledge of the encryption key as this key is an intermediate result within a closed process which is protected from external access.
  • The software producer 12 may then transmit the encrypted code/data to the customer location 13. At the customer location 13, the encrypted embedded code/data is received and fed to the secure boot loader 19 of the device 17 to program the device 17. The secure boot loader 19 decrypts the encrypted embedded code/data and stores the decrypted embedded code/data in a memory, in particular a flash memory, of the device 17.
  • FIG. 2 shows a simplified schematic diagram of a further example environment wherein a system according to a further embodiment of the invention may be implemented.
  • A device 27 is produced by a manufacturer, e.g. a semiconductor manufacturer, at the manufacturers location, e.g. a semiconductor plant 11, sold to a customer and delivered to the customer location 13. In addition, a supplier which can be a software producer 12 in this example, provides the customer with an embedded code or data designed for the device 27 bought by the customer. The customer will then program the device 27 bought from the manufacturer at their location 13 with the embedded code or data provided by the supplier or software producer 12 in this example. The customer can be a distributor which customizes the devices, a company which integrates the devices in their own products or a user, for example.
  • In this embodiment which provides an increased protection of the embedded code or data, the (semiconductor) manufacturer provides each device with a first encryption key which may be stored in a memory, such as a flash memory, of the device 27. Thus, the customer obtains the first encryption key together with the ordered device 27.
  • The supplier or, in this example, software producer 12 provides the embedded code or data designed for the device 27 to the customer in encrypted form, in this case, encrypted with a second, different encryption key. The second encryption key for encrypting the embedded code or data is also transmitted to the customer in encrypted form, wherein the second encryption key is encrypted with the first encryption key.
  • However, in order to avoid revealing the first encryption key to the supplier, the manufacturer may perform the encryption of the second encryption key with the first encryption key and provide the software producer with the encrypted second encryption key.
  • Alternatively, the semiconductor manufacturer may provide the software producer 12 with an identification (ID) number allocated to the respective device to enable the software producer 12 to generate the first encryption key based on the ID number using a master key or a database. The reproduced first encryption key is used to encrypt the second encryption key without revealing the first encryption key itself: Though the software producer 12 may generate the first encryption key as an intermediate result, this intermediate result is directly input to the encryption process for the second encryption key and is otherwise not accessible. Thus, also in this case, the software producer does not get knowledge of the first encryption key as it is an intermediate result within a closed process which is protected from external access.
  • The software producer 12 then transmits both the encrypted embedded code/data and the encrypted second encryption key to the the customer location.
  • At the customer location, the encrypted embedded code/data and the encrypted second encryption key are received and fed to the secure boot loader 29 of the device 27. The secure boot loader 29 decrypts the encrypted second encryption key using the first encryption key stored within the device 27, decrypts the embedded code or data using the decrypted second encryption key and stores the decrypted embedded code/data in a memory, e.g. a flash memory, of the device 27. The embedded code or data can then be used for programming the device 27.
  • In both embodiments described above, received encrypted data may be downloaded first into a random access memory (RAM) of the device 17 and 27, respectively, using the secure boot loader 19 and 29, respectively, which may be part of the firmware of the device 17 and 27, respectively. The secure boot loader 19 and 29, respectively, may be in the form of a flash memory as well. Based on the type of data, the secure boot loader 19 and 29, respectively, may then perform the decryption and programming to targeted locations on a flash memory.
  • With the encryption key controlled system, the specific number of devices authorized to run or use the embedded code or data is controllable and may also be provided to the software producers as a value-added service. By including different (first) encryption keys in the devices produced by the semiconductor manufacturer, the number of devices which can use the encrypted embedded code or data is limited. The group of devices which are allocated a common encryption key is arbitrary. For example, one unique encryption key may be allocated to one batch of devices or to all devices provided to a certain customer. Even a unique encryption key could be allocated to each single device which would, however, involve rather high administrative effort.
  • In the embodiment wherein the software producer generates a second encryption key, the software producer obtains a rough estimation of distributed embedded codes/data. Given that a separate second encryption key is generated for each first encryption key, the total number of distributed codes/data may be obtained by multiplying the number of generated second encryption keys by the number of devices which are furnished with a common first encryption key.
  • With the encryption key controlled system and/or the corresponding method described above, further data and/or codes for configuring devices may securely be transferred, too. The task of device variant configuration may be delegated to the customer by providing the customer with an encrypted file which performs the desired configuration when executed. For example, special hardware features may be enabled or disabled, such as access to memory regions, etc. In particular, a specific set of hardware features required for a certain embedded code may also be activated by such a file transmitted in encrypted form. Similarly, an encrypted peripheral activation code (PAC) may be transmitted to the customer so that the customer can tailor a feature set according to the application's needs and unlock dedicated peripherals. Furthermore, a customer may also be offered the possibility to upgrade a device bought in the past by purchasing the appropriate encrypted file which activates the desired additional features when executed.
  • Furthermore, an update of the second encryption key may be facilitated by securely transferring the new second encryption key in encrypted form, encrypted with the first encryption key, for example.
  • Any encryption algorithm may be used in order to provide suitable encryption means for the embodiments of the invention. Accordingly, encryption may be based on symmetric encryption algorithms such as AES (Advanced Encryption Standard), DES (Data Encryption Standard), Triple-DES, Blowfish, Serpent, Twofish, etc., or public-key cryptography also called asymmetric key cryptography which uses asymmetric key algorithms (e.g. RSA). One embodiment of the invention uses AES as encryption algorithm.
  • A hybrid cryptosystem may also be used. The hybrid cryptosystem is itself a public-key system, which encapsulates a symmetric-key scheme. Thus, for a large library software, the bulk of the work in encryption/decryption could be done by the more efficient symmetric-key scheme, while the inefficient public-key scheme is only used to encrypt/decrypt a short session key value. As soon as the session key is decrypted using the private key, the efficient implementation of the symmetric-key decryption may be used for flash programming. In a hybrid system, the first encryption key used in embodiments described above may be an asymmetric key and the second encryption key may be a symmetric key, for example.
  • FIG. 3 shows an example method according to an embodiment of the invention, in particular, a method for securely transferring embedded code or data designed by a supplier for a device produced by a manufacturer to a customer. The example method comprises storing a first encryption key in a memory of a device to be delivered to a customer at 302, and encrypting embedded code or data designed for the device using a second encryption key at 304. The method further comprises encrypting the second encryption key using the first encryption key at 306, sending the encrypted embedded code or data and the encrypted second encryption key to a customer location at 308, and receiving the encrypted embedded code or data and the encrypted second encryption key at the customer location at 310. Still further, the method comprises decrypting the received encrypted second encryption key at the customer location using the first encryption key stored in the device at 312, and decrypting the received encrypted embedded code or data at the customer location using the decrypted second encryption key at 314. It is, however, to be appreciated that the order of steps depicted in FIG. 3 and described above is only one example sequence and many other sequences of actions are also possible.
  • Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.

Claims (21)

1. A device comprising:
a secure boot loader;
a first encryption key stored in a memory of the device;
wherein the secure boot loader is configured to:
receive a second encryption key encrypted with the first encryption key;
receive embedded code or data encrypted with the second encryption key;
decrypt the received encrypted second encryption key using the first encryption key; and
generate decrypted embedded code or data using the decrypted second encryption key.
2. The device of claim 1, wherein the decrypted embedded code comprises embedded software code to program the device.
3. The device of claim 1, wherein the secure boot loader is further configured to:
store the decrypted embedded code or data in a data storage of the device.
4. The device of claim 3, wherein the data storage comprises a flash memory.
5-7. (canceled)
8. The device of claim 1, wherein the device is a semiconductor device.
9. The device of claim 1, wherein a firmware is stored on the device, the firmware comprising the secure boot loader.
10. (canceled)
11. The device of claim 1, wherein the first encryption key is based on an identification number (ID) associated with the device.
12. A system for securely decrypting embedded code or data, the system comprising:
a device comprising a boot loader; and
a first encryption key,
wherein the boot loader is configured to:
receive a second encryption key encrypted with the first encryption key; and
decrypt the received encrypted second encryption key using the first encryption key.
13. The system of claim 12, wherein the boot loader is further configured to:
receive embedded code or data designed for the device and encrypted with the second encryption key; and
decrypt the embedded code or data using the decrypted second encryption key.
14. The system of claim 13, comprising:
a plurality of devices, each of the plurality of devices comprising a respective boot loader configured to:
receive the second encryption key encrypted with the first encryption key;
receive the embedded code or data encrypted with the second encryption key;
decrypt the received encrypted second encryption key using the first encryption key; and
decrypt the embedded code or data using the decrypted second encryption key.
15. A method for decrypting embedded code or data by a device comprising a boot loader, the method comprising:
receiving a second encryption key encrypted with a first encryption key;
receiving embedded code or data encrypted with the second encryption key;
decrypting the received encrypted second encryption key using the first encryption key; and
generating, by the boot loader of the device, decrypted embedded code or data using the decrypted second encryption key.
16. The method of claim 15, wherein the first encryption key is generated based on an identification number of the device.
17. The method of claim 15, wherein the second encryption key is generated by a manufacturer of the device.
18. The method of claim 15, wherein the decrypted embedded code comprises code to enable a feature set of the device.
19. The method of claim 15, wherein the decrypted embedded code comprises code to enable or disable special hardware features of the device.
20. The method of claim 15, wherein the decrypted embedded code comprises peripheral activation code (PAC).
21. The device of claim 1, wherein the decrypted embedded code comprises code to enable a feature set of the device.
22. The device of claim 1, wherein the decrypted embedded code comprises code to enable or disable special hardware features of the device.
23. The device of claim 1, wherein the decrypted embedded code comprises peripheral activation code (PAC).
US14/799,765 2012-11-28 2015-07-15 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer Abandoned US20150347758A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/799,765 US20150347758A1 (en) 2012-11-28 2015-07-15 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/687,066 US9116841B2 (en) 2012-11-28 2012-11-28 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer
US14/799,765 US20150347758A1 (en) 2012-11-28 2015-07-15 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/687,066 Continuation US9116841B2 (en) 2012-11-28 2012-11-28 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer

Publications (1)

Publication Number Publication Date
US20150347758A1 true US20150347758A1 (en) 2015-12-03

Family

ID=50774379

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/687,066 Active US9116841B2 (en) 2012-11-28 2012-11-28 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer
US14/799,765 Abandoned US20150347758A1 (en) 2012-11-28 2015-07-15 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/687,066 Active US9116841B2 (en) 2012-11-28 2012-11-28 Methods and systems for securely transferring embedded code and/or data designed for a device to a customer

Country Status (2)

Country Link
US (2) US9116841B2 (en)
CN (1) CN103856322B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210133315A1 (en) * 2019-10-31 2021-05-06 Vmware, Inc. Unifying hardware trusted execution environment technologies using virtual secure enclave device

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104573414A (en) * 2015-01-06 2015-04-29 浪潮电子信息产业股份有限公司 Verification control method for guaranteeing software activation
ES2809698T3 (en) * 2015-03-03 2021-03-05 Wonderhealth Llc Access control for data encrypted in machine-readable identifiers
DE102015212657A1 (en) * 2015-07-07 2017-01-12 Siemens Aktiengesellschaft Providing a device-specific cryptographic key from a cross-system key for a device
US10810321B2 (en) 2016-08-11 2020-10-20 Intel Corporation Secure public cloud
US10503894B2 (en) * 2016-08-30 2019-12-10 Ncr Corporation Secure process impersonation
CN107808099B (en) * 2016-09-08 2021-03-16 北京自动化控制设备研究所 Embedded software encryption/decryption system and method
US10885199B2 (en) * 2016-09-26 2021-01-05 Mcafee, Llc Enhanced secure boot
US10049218B2 (en) 2016-12-07 2018-08-14 Google Llc Rollback resistant security
GB2581161A (en) * 2019-02-05 2020-08-12 Trustonic Ltd Software encryption
US11044118B1 (en) 2019-06-28 2021-06-22 Amazon Technologies, Inc. Data caching in provider network substrate extensions
US11431497B1 (en) * 2019-06-28 2022-08-30 Amazon Technologies, Inc. Storage expansion devices for provider network substrate extensions
US11659058B2 (en) 2019-06-28 2023-05-23 Amazon Technologies, Inc. Provider network connectivity management for provider network substrate extensions
US11411771B1 (en) 2019-06-28 2022-08-09 Amazon Technologies, Inc. Networking in provider network substrate extensions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1304827A1 (en) * 2001-10-08 2003-04-23 Beta Research GmbH Secure data transmission method
WO2006013477A1 (en) * 2004-07-29 2006-02-09 Koninklijke Philips Electronics N.V. Device and method for providing and decrypting encrypted network content using a key encryption key scheme
US7802085B2 (en) * 2004-02-18 2010-09-21 Intel Corporation Apparatus and method for distributing private keys to an entity with minimal secret, unique information
US20120060039A1 (en) * 2010-03-05 2012-03-08 Maxlinear, Inc. Code Download and Firewall for Embedded Secure Application

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5398285A (en) * 1993-12-30 1995-03-14 Motorola, Inc. Method for generating a password using public key cryptography
US7237121B2 (en) * 2001-09-17 2007-06-26 Texas Instruments Incorporated Secure bootloader for securing digital devices
US7194633B2 (en) * 2001-11-14 2007-03-20 International Business Machines Corporation Device and method with reduced information leakage
US7742992B2 (en) * 2002-02-05 2010-06-22 Pace Anti-Piracy Delivery of a secure software license for a software product and a toolset for creating the software product
US8041957B2 (en) * 2003-04-08 2011-10-18 Qualcomm Incorporated Associating software with hardware using cryptography
US20060059372A1 (en) * 2004-09-10 2006-03-16 International Business Machines Corporation Integrated circuit chip for encryption and decryption having a secure mechanism for programming on-chip hardware
US20090323971A1 (en) * 2006-12-28 2009-12-31 Munguia Peter R Protecting independent vendor encryption keys with a common primary encryption key
US8892855B2 (en) * 2010-08-10 2014-11-18 Maxlinear, Inc. Encryption keys distribution for conditional access software in TV receiver SOC

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1304827A1 (en) * 2001-10-08 2003-04-23 Beta Research GmbH Secure data transmission method
US7802085B2 (en) * 2004-02-18 2010-09-21 Intel Corporation Apparatus and method for distributing private keys to an entity with minimal secret, unique information
WO2006013477A1 (en) * 2004-07-29 2006-02-09 Koninklijke Philips Electronics N.V. Device and method for providing and decrypting encrypted network content using a key encryption key scheme
US20120060039A1 (en) * 2010-03-05 2012-03-08 Maxlinear, Inc. Code Download and Firewall for Embedded Secure Application

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210133315A1 (en) * 2019-10-31 2021-05-06 Vmware, Inc. Unifying hardware trusted execution environment technologies using virtual secure enclave device

Also Published As

Publication number Publication date
CN103856322A (en) 2014-06-11
CN103856322B (en) 2018-09-14
US20140149748A1 (en) 2014-05-29
US9116841B2 (en) 2015-08-25

Similar Documents

Publication Publication Date Title
US9116841B2 (en) Methods and systems for securely transferring embedded code and/or data designed for a device to a customer
US11811914B2 (en) Blockchain-based digital rights management
US9602282B2 (en) Secure software and hardware association technique
US10140612B1 (en) POS system with white box encryption key sharing
US7313828B2 (en) Method and apparatus for protecting software against unauthorized use
US8875299B2 (en) User based content key encryption for a DRM system
CN104221023B (en) Methods, devices and systems for digital rights management
CN106304040A (en) The management method of Mobile solution, device
US20200356642A1 (en) Enabling an encrypted software module in a container file
CN106471766A (en) Crypto chip and correlation technique
CN100593296C (en) A remote upgrading method realized by shared secret key
CN105574441A (en) Embedded firmware protection method and device
US9166783B2 (en) Protection method, decryption method, player, storage medium, and encryption apparatus of digital content
US20090202077A1 (en) Apparatus and method for secure data processing
JP4989806B2 (en) System and method for remote device registration
EP4280533A1 (en) Management of root key for semiconductor product
EP3193274B1 (en) Secure memory storage
CN111737660A (en) Method, system and storage medium for realizing software authorization

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION