Security of Embedded Devices Using Device Identifiers Throughout the Device Lifecycle

Abstract

The present invention discloses a device, which includes a database having a device profile and a device programmer. The device programmer includes instructions. When the instructions are read and executed by a processor, the device programmer is caused to identify a device identifier of an electronic device. Based on the device identifier, the device programmer is further caused to access device data from the database. Based on the device data, the device programmer is further caused to determine a writable area of a memory of the electronic device. Based on the determination of the writable area of the memory of the electronic device, the device programmer is further caused to write data to the area of the memory.

Description

[0001] Priority

[0002] This patent application claims priority to U.S. Provisional Patent Application No. 62 / 867,552, filed Jun. 27, 2019, the content of which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure relates to electronic security and, more particularly, to tracking the security lifecycle of an embedded device via a device identifier (ID). Background Art

[0004] On-chip instrumentation for various semiconductor devices can conform to any number of industry standards, such as JTAG or IEEE 1149. The manufacture of semiconductor devices can be verified through testing using such protocols. During the manufacture of semiconductor devices, a device programmer can be used to write data into such semiconductor devices. The data can be written into non-volatile memory in such devices. In addition, firmware and software can be loaded onto such devices.

[0005] Semiconductor devices can operate in different modes, such as a debug mode or a released end-user mode. The debug mode can access certain elements of the available semiconductor device such that engineering, test, or verification personnel associated with the production of the semiconductor device can evaluate the quality or operation of the semiconductor device. The released end-user mode can allow the semiconductor device to operate in a manner intended for the end-user of the semiconductor device.

[0006] In a typical application, the state of a semiconductor device is determined based on the stage in the lifecycle in which the semiconductor device physically exists, whether in production in a factory, in verification or testing in a factory, or in the hands of an end-user. In addition, in a typical application, the determination of the state of a semiconductor device is performed by observing the behavior of the semiconductor device. For example, if a semiconductor device presents its debug mode options, the semiconductor device can be determined to be in the debug mode.

[0007] The inventors of embodiments of the present disclosure have found that in semiconductor devices that include security keys and security features, such as where these security keys and security features are configured to provide secure boot or secure debug, it is important to independently determine the security state of the semiconductor device such that the semiconductor device can be verified and appropriately used and allocated. For example, it may be desirable to allow a developer or test engineer to view and modify the bootloader code while debugging the secure bootloader on a semiconductor device. It may also be desirable to prevent an end-user from having the same behavior on the same semiconductor device. Embodiments of the present disclosure can utilize mechanisms on the device to provide such different levels of security. Summary of the Invention

[0008] Embodiments of the present disclosure may include an apparatus. The apparatus may include a database that includes a plurality of device profiles. The apparatus may include a device programmer having instructions that, when read and executed by a processor, cause the device programmer to identify a device identifier of an electronic device, then access device data from the database based on the device identifier, then determine an area of the memory of the electronic device that can be written based on the device data, and then write data to the area of the memory of the electronic device based on the determination of the area of the memory of the electronic device that can be written.

[0009] Embodiments of the present disclosure may include other apparatuses. The other apparatus may include a memory and a device identifier configured to represent a production stage of the apparatus and allow access to a first area of the memory that can be written.

[0010] Embodiments of the present disclosure may include an article. The article may include a non-transitory machine-readable medium. The medium may include instructions that, when read and executed by a processor, cause the processor to identify a device identifier of an electronic device, then access device data from the database based on the device identifier, then determine an area of the memory of the electronic device that can be written based on the device data, and then write data to the area of the memory of the electronic device based on the determination of the area of the memory of the electronic device that can be written.

[0011] Embodiments of the present disclosure may include other articles. The article may include a non-transitory machine-readable medium. The medium may include instructions that, when read and executed by a processor, cause the processor to provide access to an electronic device for a device programmer, provide a device identifier from the memory to the device programmer, and represent a production stage of the apparatus and allow access to an area of the memory that can be written based on the device identifier.

[0012] Embodiments of the present disclosure may include a method. The method may include accessing an electronic device, identifying a device identifier of the electronic device, then accessing device data from a database that includes device profiles based on the device identifier, then determining an area of the memory of the electronic device that can be written based on the device data, and then writing data to the area of the memory of the electronic device based on the determination of the area of the memory of the electronic device that can be written.

[0013] Embodiments of the present disclosure may include other methods. The method may include: providing access to an electronic device for a device programmer, providing a device identifier from the memory to the device programmer, and representing a production stage of the electronic device and allowing access to a first area of the memory that can be written based on the device identifier. Description of the Drawings

[0014] Figure 1Illustrates an exemplary system for tracking the security lifecycle of an embedded device by device ID according to an embodiment of the present disclosure.

[0015] Figure 2 Illustrates the process of a single programming device having different IDs according to different stages of the security lifecycle according to an embodiment of the present disclosure.

[0016] Figure 3 Illustrates the memory mapping of a memory given different device IDs according to an embodiment of the present disclosure.

[0017] Figure 4 Illustrates an exemplary method for providing a security lifecycle for a device according to an embodiment of the present disclosure. Detailed Description

[0018] Embodiments of the present disclosure may include an apparatus. The apparatus may be included in a system. The system may be a production system for manufacturing electronic devices, a test or verification system for validating electronic devices, an associated institution system for customizing electronic devices, or an end-user system. The apparatus may include a database that includes device profiles. The database may be implemented in any suitable manner. The apparatus may include a device programmer. The device programmer may be configured to access an electronic device, read an identifier, write an identifier, and otherwise configure the electronic device using an interface such as JTAG. The device programmer may be implemented by any suitable combination of analog circuitry, digital circuitry, or instructions executed by a processor. The instructions may be stored on a non-transitory machine-readable medium. When read and executed by the processor, the instructions cause the device programmer to identify a first device identifier of a first electronic device. The identifier may be set in a one-time programmable fuse. Based on the first device identifier, the device programmer may access first device data from the database. The device data may include the memory mapping of the corresponding electronic device. Based on the first device data, the device programmer may determine a first region of the memory of the first electronic device that can be written. Based on the determination of the first region of the memory of the first electronic device that can be written, the device programmer may write data to the first region of the memory of the first electronic device.

[0019] In combination with any of the above embodiments, the first device data may include a first memory mapping of the first device, which is configured to define a first region of the memory of the first electronic device as programmable.

[0020] In combination with any of the above embodiments, the first memory mapping may be further configured to define a second region of the memory of the first electronic device that is not programmable.

[0021] In combination with any of the above-described embodiments, the first memory mapping may be further configured to define a second region of the memory of the first electronic device as invisible from use of the first electronic device.

[0022] In combination with any of the above-described embodiments, the device programmer may be further configured to replace the first device identifier with a second device identifier on the first electronic device after writing data to a first region of the memory of the first electronic device. The second device identifier may overwrite the first device identifier by setting an additional fuse in the memory location that defines the identifier of the first electronic device.

[0023] In combination with any of the above-described embodiments, the second device identifier may be configured to define a third region of the memory that may be written to.

[0024] In combination with any of the above-described embodiments, the second device identifier may be configured to prevent one or more other devices from writing data to a first region of the memory of the first electronic device.

[0025] In combination with any of the above-described embodiments, the second device identifier may be associated with a second memory mapping of the first electronic device, the second memory mapping being configured to define a third region of the memory of the first electronic device as programmable.

[0026] In combination with any of the above-described embodiments, the second device identifier may be configured to define that a first region of the memory is not programmable.

[0027] In combination with any of the above-described embodiments, the device programmer may be further configured to identify a third device identifier of a second electronic device and, based on the third device identifier, determine a different device programmer than the device programmer that is configured to write data to the second electronic device.

[0028] In combination with any of the above-described embodiments, the first device identifier may be configured to allow access to debug features of the first electronic device through the first memory mapping; and the second device identifier may be configured to deny access to debug features of the first electronic device through the second memory mapping.

[0029] In combination with any of the above-described embodiments, the device identifier may identify a stage of the life cycle of the electronic device. In another embodiment, when the device identifier changes, it may be changed to a larger number, but may not be reversibly changed back to the original or a smaller number. In yet another embodiment, the larger number may represent a subsequent stage of the life cycle of the electronic device.

[0030] Embodiments of the present disclosure may include other devices. The device may implement any of the electronic devices of the above embodiments. The device may include a memory and a first device identifier configured to represent a production stage of the device and to permit access to a first writable region of the memory. The device identifier may be programmed via an electronic fuse.

[0031] In combination with any of the above embodiments, the first device identifier may be configured to prevent programming of a second region of the memory.

[0032] In combination with any of the above embodiments, the second region of the memory may not be mapped for use by the device.

[0033] In combination with any of the above embodiments, the first device identifier may be configured to be replaced by a second device identifier.

[0034] In combination with any of the above embodiments, the second device identifier may be configured to define a third writable region of the memory.

[0035] In combination with any of the above embodiments, the second device identifier may be further configured to prevent writing data to the first region of the memory.

[0036] In combination with any of the above embodiments, the second device identifier may be further configured to define that the first region of the memory is non-programmable.

[0037] In combination with any of the above embodiments, the first device identifier may be configured to permit access to a debug feature of the device via a first memory mapping, and the second device identifier may be configured to deny access to the debug feature of the device via a second memory mapping.

[0038] Embodiments of the present disclosure may include an article of manufacture including any non-transitory machine-readable medium of any of the above embodiments.

[0039] Embodiments of the present disclosure may include a method performed by any device of any of the above embodiments.

[0040] Figure 1 is a diagram of an exemplary system 100 for tracking the security lifecycle of an embedded device via a device ID in accordance with an embodiment of the present disclosure.

[0041] System 100 can be configured to track the security life cycle of any suitable device, such as device 101. System 100 can use JTAG or other suitable protocols to program, test, and access the content on device 101. Device 101 can be implemented in any suitable manner, such as a semiconductor device with firmware, a microcontroller, a chip, or any other suitable electronic device. Device 101 can include memory 116. Various parts of System 100 can be configured to edit the content of memory 116 for device 101, or provide one or more IDs for device 101. In one embodiment, device 101 can include multiple IDs at a given time in the life cycle. In another embodiment, only one such ID may be recognized or available at a given time. In another embodiment, device 101 can include different IDs at different times in the life cycle. In Figure 1 this, device 101 is shown moving to and being processed by various parts of System 100.

[0042] The security life cycle of device 101 can include any suitable number and types of stages. The security for accessing different aspects or modes of device 101 can change depending on the stage of the security life cycle that device 101 is in at a given time.

[0043] System 100 can include any suitable number and types of other subsystems therein. For example, System 100 can include a production system 104, a test system 106, or an associated agency system 108. Additionally, System 100 can produce device 101 for use by an end user with another system 132, which can be or can not be part of System 100.

[0044] In terms of the desired configuration of device 101, the stages of the security life cycle of device 101 can roughly correspond to the subsystems of System 100. In other solutions, based on the presence of a given device within a given subsystem, it is assumed that the device is in a given stage of the security life cycle. However, in one embodiment, System 100 can use the device ID to identify which stage of the security life cycle device 101 should be in or be configured for, regardless of whether device 101 is present in a particular subsystem or outside of System 100.

[0045] The ID of device 101 can be in any suitable form. In one embodiment, the ID of device 101 can uniquely identify device 101 across all instances of device 101. In another embodiment, the ID of device 101 can uniquely identify the model, category, type, version, or other classification assigned to or to which device 101 belongs. In such embodiments, across all other instances of devices having the same model, category, type, version, or other classification as device 101, the ID of device 101 may not uniquely identify device 101. In yet another embodiment, the ID of device 101 can include information about the hierarchical structure of the model, category, type, version, or other classification assigned to device 101. In such embodiments, the ID can specify the classification to which device 101 and other devices of various models, categories, types, versions, or other classifications belong. These devices can be related by a set of common characteristics, but differ in other characteristics. In yet another embodiment, the ID of device 101 can include more than one possible ID or a set of IDs. Such IDs can be a series of IDs, ID values, or possible IDs. In yet another embodiment, the ID of device 101 can implicitly specify the characteristics of device 101. Additionally, the ID of device 101 can include any permutation of any of these embodiments.

[0046] By using the device ID to identify the stage of the security lifecycle, errors can be reduced where it is incorrectly assumed that the device is in a different security lifecycle stage. Such incorrect assumptions can lead to errors. For example, the creator of device 101 may expect that the debug mode is not available after device 101 is provided from the production and test facility. In another example, the programming of device 101 can be permanent programming using some techniques. These mechanisms include one-time programming (OTP), electronic fuses, and other suitable one-write mechanisms. While such techniques can be used to permanently write data in the non-volatile memory of some parts of device 101, in such configurations, a later entity can still incorrectly or maliciously rewrite the unwritten bits. For example, if a memory location in device 101 is written with the value "0001" in a fuse during production, the "0" value can be the default value in the target memory and thus not specifically written to set the resulting "0" value. However, these "0" values can remain writable. In contrast, the "1" value can be written and thus made immutable. If device 101 is incorrectly reintroduced into the same production stage for a different intended use, the same memory location can be rewritten with "1000", resulting in "1001" in the memory location. This can have catastrophic consequences for the operation of device 101, such as rendering device 101 inoperable. System 100 can provide increased security during the production of device 101 such that device 101 is less vulnerable to attacks and write errors.

[0047] Production system 104 may include a manufacturing subsystem, a production subsystem, or any other subsystem configured to create device 101. Although referred to as a "test" system, test system 106 may include a manufacturing test, verification, quality assurance, or development engineering subsystem. Test system 106 may be configured to evaluate the performance of device 101 produced by production system 104. Test system 106 may evaluate such performance as part of the production of device 101 for end - use or as part of the production of device 101 as part of an iterative engineering design process. Thus, device 101 may be intended for release, sale, or distribution to an end - user, or may be intended only for internal use within an entity that designs instances of device 101. Production system 104 and test system 106 may be included as part of the same logical entity 102, which is used to produce instances of device 101 for consumption and use by other entities.

[0048] Any other suitable entity may consume or use an instance of device 101. For example, device 101 may be used by an end - user with another system 132 in a real - world application external to system 100. In another example, other entities such as an affiliated agency system 108 may make further modifications, customizations, additions, or other changes to an instance of device 101. Such changes may be made to an instance of device 101 before the end - user will use it. For example, an instance of device 101 may be produced by logical entity 102 with various available options that can be further customized, such as storage space, clock speed, number of channels, peripherals, or functionality. Such storage space may include, for example, options to provide 512MB, 256MB, 128MB, or 64MB of memory available to the end - user. Such functionality may include, for example, analog - to - digital conversion that can be implemented as a multimeter or an oscilloscope for the end - user, and the specific instance of device 101 can be customized based on which particular use (multimeter or oscilloscope) the end - user will use. Such functionality may also include, for example, selecting different communication protocols, such as I2C or SPI. The specific instance of device 101 can be customized based on which particular use (I2C or SPI) the end - user will use. Such peripherals may include, for example, specific timers, counters, pulse - width modulators, encryption engines, and decryption engines, or any other suitable mechanism that can be built into device 101 and selectively enabled. The selection of features may be performed in affiliated agency system 108 as described above, and may also be performed in production system 104.

[0049] For example, the ID of device 101 may be in the form of WWWW - XXXX - YYYY - Z. This exemplary ID is presented merely as an illustration, and the fields of the ID of device 101 may be longer or shorter in any order, may be optional depending on a given specific implementation, or may have any other suitable variation.

[0050] The string of "W" values can define the general classification of the product to which device 101 belongs. Based on the string of "W" values, a part of system 100 can define a set of characteristics for device 101, or assume that device 101 will have such a set of characteristics. Such a set of characteristics can be a subset of the total characteristics of device 101.

[0051] The string of "X" values can define the specific model, version, or other classification of the product to which device 101 belongs. Based on the string of "X" values, combined with the string of "W" values alone, a part of system 100 can define a set of characteristics for device 101, or assume that device 101 will have such a set of characteristics. Such a set of characteristics can be a subset or the entire set of the total characteristics of device 101.

[0052] The string of "Y" values can define the specific characteristics of device 101, or can also define a more specific model, version, or other classification of the product to which device 101 belongs. Based on the string of "Y" values, combined with the strings of "W" and "X" values alone, a part of system 100 can define a set of characteristics for device 101, or assume that device 101 will have such a set of characteristics. Such a set of characteristics can be a subset or the entire set of the total characteristics of device 101.

[0053] Each of the "W", "X", and "Y" values can be set by any suitable part of system 100. For example, production system 104 can set the "W" value, test system 106 can set the "X" value, and associated agency system 108 can set the "Y" value. However, in another example, production system 104 or test system 106 can set all of the "W", "X", and "Y" values. Only a subset of the "W", "X", and "Y" values can be set for a given device ID, and the other values that have not been set can be wildcards or random values. For example, the "W" value can reflect the product line of device 101, the "X" value can reflect the model within the product line of device 101, and the "Y" value can reflect the specific characteristics or options of the model of device 101. For example, if only the "W" and "X" values are set in test system 106, then the "Y" value can be a random value or a wildcard value. Test system 106 can assume that the characteristics of device 101 include the characteristics specified by the "W" and "X" values, and the characteristics defined by the "Y" value can optionally be included at a later time. Therefore, test system 106 can be configured to test all permutations of the characteristics that will be defined by the "Y" value.

[0054] In one embodiment, system 100 may use a "Z" value to indicate the current stage of device 101 with respect to the security life cycle. In another embodiment, the "Z" value may be set by production system 104 or test system 106. In yet another embodiment, the "Z" value may also be set by affiliated agency system 108. Production system 104 may be configured to set the "Z" value to a first value. Test system 106 may be configured to update the "Z" value to a second value. The first value and the second value may be the same or different. Affiliated agency system 108 may be configured to update the "Z" value to yet another third value.

[0055] In one embodiment, a particular "Z" value and thus ID may indicate that device 101 will be used within a particular context, or that device 101 was previously issued by a part of system 100. For example, a particular "Z" value and thus ID (such as zero) may indicate that device 101 has been prepared and will be used within production system 104. Another particular "Z" value (such as 1) may indicate that device 101 has been prepared, issued by production system 104, and will be used within test system 106. Yet another particular "Z" value and thus ID (such as 2) may indicate that device 101 has been prepared, verified, issued by test system 106, and will be used within affiliated agency system 108. Yet another particular "Z" value and thus ID (such as 3) may indicate that device 101 has been released by system 100 for end-user use. Although these example values are given, more or fewer different values may be used. For example, particular different "Z" values and IDs may be used for different stages used within test system 106 or production system 104.

[0056] Based on different IDs, such as those embodied by different "Z" values, other users of system 100 and device 101 may be able to identify the stage of the security life cycle to which device 101 belongs and which part of system 100 device 101 will be used for. Security features may be enabled or disabled based on such IDs. When a given part of system 100 is to provide device 101 to another part of system 100 or to an end user and is to advance the security life cycle of device 101, the ID may be changed or replaced to reflect the next stage.

[0057] Each subsystem of system 100 may include a device programmer 110. The device programmer 110 may be configured to write data to device 101. The device programmer 110 may be implemented by analog circuitry, digital circuitry, instructions executed by a processor (not shown), or any suitable combination thereof. The specific implementation of the device programmer 110 may vary between the subsystems of system 100. For example, the device programmer 110A of production system 104 may be able to write to portions of the memory 116 of device 101 that are inaccessible to other subsystems based on the device ID. The device programmer 110B of test system 106 may be able to write to portions of the memory 116 of device 101 that are inaccessible to the associated agency subsystem 108 based on the device ID.

[0058] Each subsystem of system 100 may include a database 112. The database 112 may be implemented in any suitable manner, such as a file system, a relational database, or other suitable organization. The database 112 may include configuration files, files, or data instances for programming device 101 in a particular manner or for mapping memory that may be available in memory 116. Such files or data instances may be referred to as.pic files. The content of each instance of the database 112 may vary between the subsystems of system 100. For example, the database 112A of production system 104 may include files for device 101 that are not available in other instances of the database 112. The database 112B may include files for device 101 that are not available in the database 112C.

[0059] In one embodiment, different portions of device 101 may be available to be written during different stages of the security lifecycle. In another embodiment, such different portions of device 101 may be made available for writing by using different device IDs assigned to device 101 during different stages of the security lifecycle. A given device ID may define the device data of device 101, such as the memory mapping of memory 116, based on the content of the database 112. The memory mapping of memory 116 may define, for example, which regions or portions of memory 116 are available for access or writing, which portions of memory 116 are available for reading from, or which portions of memory 116 remain undefined and are not available for reading or writing.

[0060] The storage of the device ID can be performed in any suitable manner. The device ID can be stored in such a way that it can only be changed by incrementing or decrementing its count. For example, the storage of the device ID can be performed by a fuse and a thermometer counter so that the device ID can only be incremented. The larger the number of the device ID, the further the device has progressed in the product life cycle within the system. In addition, the larger the number of the device ID, the higher the reliability of the device. However, in one embodiment, or regardless of where the device ID is stored, it can be accessed by any device programmer in the system or by the end user. The device ID can be read by, for example, a 2-wire or 4-wire JTAG or by software.

[0061] For example, the production system 104 can create an instance of the device 101. The device 101 can include a memory 116 that is completely empty. The device programmer 110A can be configured to issue an initial device ID to the device 101, such as ID1 118. ID1 118 can have a "Z" value or any suitable value that indicates to the reader that ID1 118 is in a stage of the security life cycle associated with the production system 104. By referring to the database 112, the device ID can specify the characteristics of the device 101, such as the memory map as described above, and the selection of the core, enabled peripherals, or any other suitable characteristics. ID1 118 can be stored in the memory 116 or any other suitable part of the device 101.

[0062] The device programmer 110A can be configured to write to the memory 116. Specifically, the device programmer 110A can be configured to write to a specific part or region of the memory 116, such as sections 117, 120. The content of the data written to section 120 can be, for example, ID1 118, a public / private key for verification, settings, or any other suitable data. Specifically, the IDs used in the system 100 can each be written to section 117.

[0063] When the device 101 has completed all aspects of the production system 104, the device programmer 110A can assign a different ID to the device 101, such as ID2 119. ID1 118 can be rewritten in the section 117 or stored in a part of the memory 116 that is no longer accessible in subsequent stages of the security life cycle. ID1 118 can be configured to be replaced by ID2 119 by being overwritten at the same location in the section 117, for example, or included in a part of the memory 116 that is no longer accessible in subsequent stages, where ID2 119 is included in a part of the memory 116 that is accessible in subsequent stages. Preventing such access can be performed by a memory map associated with ID2 119 that does not include the location where ID1 118 is stored. However, in one embodiment, ID2 119 can be stored in the section 117 of the memory 116 by writing a fuse that changes ID1 118 to ID2 119.

[0064] The device 101 can then be provided to the test system 106.

[0065] In the test system 106, ID2 119 can be read by the device programmer 110B. Based on ID2 119, the device programmer 110B can access the database 112B to determine the characteristics of the device 101, such as the memory map of the memory 116. The device programmer 110B can be configured to write data to the device 101. The data can include, for example, a public / private key written to the memory 116, or other settings. The device programmer 110B can be configured to write to a specific part of the memory 116, such as the section 122. In one embodiment, the data in the section 120 can be visible to the test system 106 and the device programmer 110B. This may be because the device programmer 110B is configured to access the memory map of the device 101 based on ID2 119, which maps the entire memory 116. In another embodiment, the data in the section 120 may not be visible or invisible to the test system 106 and the device programmer 110B, where the memory map of the device 101 based on ID2 119 can omit the section 120 from the memory map of the memory 116. The data in the section 122 can include debugging features. ID2 119 can be visible in the section 117 and mapped in the memory map of the memory 116.

[0066] When the device 101 has completed all aspects of the test system 106, the device programmer 110B can assign a different ID to the device 101, such as ID3 126. ID2 119 can be rewritten in the section 117 or may have been stored in a part of the memory 116 that is no longer accessible in subsequent stages of the secure life cycle. Preventing such access can be performed by a memory map associated with ID3 126, which does not include the location where ID2 119 is stored.

[0067] After issuing ID3 126 to the device 101, the memory map based on ID3 126 may not map the entire memory 116, thus omitting the section 120. Therefore, the associated agency system 108 or the end user may not be able to access the section 120 when accessing the same instance of the device 101. In some cases, the memory map based on ID3 126 may similarly omit the section 122. However, such a memory map may still include the section 117 so that the identifier can be read and programmed.

[0068] Then the device 101 can be provided to the associated agency system 108.

[0069] In the associated agency system 108, ID3 126 can be read by the device programmer 110C. Based on ID3 126, the device programmer 112C can access the database 112C to determine the characteristics of the device 101, such as the memory map of the memory 116. The device programmer 110C can be configured to write data to the device 101. The data can include, for example, a public / private key written to the memory 116, or other settings 130. The data can include software such as an application 128 to be loaded onto the device 101, and a digital signature of such software. The device programmer 110C can be configured to write to a specific part of the memory 116, such as the section 124 or the section 125. In one embodiment, the data in the section 124 can be visible to the end user of the device 101. In another embodiment, the data in the section 124 may not be visible to the end user of the device 101, so the data for the end user of the device 101 can be written to the section 125. Depending on the configuration of the system 100, the data in the section 122 initially used by the test system 106 may or may not be visible to the device programmer 110C. Similarly, the data in the section 120 initially used by the production system 104 may not be visible to the associated agency system 108 and thus to the end user of the device 101. Such visibility can be established by a memory map loaded from the database 112C based on ID3 126. The device 101 can be associated with a specific.pic file that sets the characteristics, memory map, and identity of the device 101 through ID3 126. According to the memory map, the identifier in the section 117 can still be visible so that the identifier can be read and programmed.

[0070] When the device 101 has completed all aspects of the associated agency system 108, the device programmer 110C can assign a different ID to the device 101, such as ID4 129. ID3 126 can be rewritten in the section 117 or may have been stored in a part of the memory 116 that is no longer accessible in subsequent stages of the security life cycle, such as being used by an end user outside the system 100. Preventing such access can be performed by a memory map associated with ID4 129, which does not include the location where ID3 126 is stored.

[0071] The device 101 can be provided to an end user who may be outside the system 100. The device 101 can have characteristics defined by one or more of the subsystems 104, 106, 108 by issuing ID4129 or setting 130. The device 101 in such an environment can be configured to interact with other systems such as system 132. System 132 can include a processor 134 and an application 136. Different parts of the memory 116 are available according to the memory map associated with ID4 129. The memory map of ID4 129 can be written to the setting 130 so that the end user does not need a database to store the memory map.

[0072] The device 101 can utilize information such as that stored in section 124 or section 125 (depending on the storage location and the sections visible to the device 101 given the memory map associated with ID4129). The device 101 can utilize such information to, for example, verify its own content, or communicate with or verify the system 132. The device 101 in the hands of the end user may only be able to view the content stored in sections 117, 124, 125 and may not be able to view the content such as those in sections 120, 122. This may be because the memory map available to the device 101 after the associated agency system 108 is issued may not map sections 120, 122. The device 101 can access the remaining unused part of the memory 116.

[0073] The different modes of operating device 101 may be available only at specific stages of the security life cycle of system 100. For example, a debug mode for operating device 101 may expose various internal operations or information of device 101 that engineers, developers, or test technicians in test system 106 may wish to use. However, the creator of device 101 may expect that such a debug mode may not be available to the end users of device 101 or associated institutional system 108. Thus, the debug mode of device 101 may be available only for, e.g., production system 104 or test system 106. System 100 may implement such a debug mode by using device IDs specific to one or more specific parts of system 100. For example, the code for the debug mode may be stored in a memory that is available only in the sections mapped for ID1 118 and ID2 119. If the section storing the debug mode code, such as section 122, cannot be accessed by the memory mapping of ID3 126 or ID4 129, then the associated institutional system 108 receiving device 101 with such an ID or the end user of device 101 may not be able to access the debug mode.

[0074] Figure 2 is an illustration of a process of programming device 101 with different IDs according to different stages of a security life cycle in accordance with an embodiment of the present disclosure. The state of device 101 is shown.

[0075] At (1), device 101 may be newly produced by production system 104 and may be completely blank. At (2), production system 104 may issue ID1 118. ID1 118 may be issued, which is associated with a.pic file such as Blank.pic that specifies that the entire one-time programmable part of memory 116 is currently programmable. A part of system 100 that reads ID1 118 may load Blank.pic as a configuration file from an associated database based on ID1 118 to determine, based on the memory mapping of the configuration file, which stage of device 101 in the security life cycle, whether any security features are available, and which parts of memory 116 are readable and programmable.

[0076] Thus, at (3), all parts of memory 116 may be available for one-time programming, or at least those parts of the memory that are configured to be programmed in this way may be available for one-time programming.

[0077] At (4), various parts of system 100 such as production system 104 or test system 106 may perform programming of device 101. Such programming may include, for example, calibration information or other information such as security keys. Some security keys may be internally available during the use of production system 104 or test system 106, but not for affiliated agency system 108 or end users. Such security keys may be written to a portion of memory 116 that is not mapped by a configuration file or memory map associated with an ID for such later stages of the security lifecycle (such as affiliated agency system 108 or end user). Other security keys are available for use by affiliated agency system 108 or end users. Such security keys may be written to a portion of memory 116 that is mapped by a configuration file or memory map associated with an ID for such later stages of the security lifecycle.

[0078] During the programming and use of keys to be used internally within system 104 or 106, ID2 119 may be issued to device 101. ID2 119 may be associated with a memory map that defines, for example, the portion of memory 116 that is accessible for such internal use by system 104, 106. These keys may be used for security debugging, testing, verification, or other processes. By issuing an additional ID (such as ID3 126), keys written to memory 116 during this stage may not be available for later stages of the security lifecycle for which there is no memory map of the region of memory 116 containing such keys.

[0079] After production system 104 and test system 106 are configured, device 101 may be ready for use by affiliated agency system 108. Affiliated agency system 108 may be configured to provide its own keys into memory 116 for its own internal use. Thus, test system 106 may issue ID3 126 to device 101. ID3 126 may be associated with a.pic file such as key.pic that maps the portion of memory 116 for affiliated agency system 108 to write its own keys.

[0080] At (5), device 101 may be released to affiliated agency system 108. At (6), affiliated agency system 108 may perform its own key programming, such as writing a public key to the portion of memory 116 mapped in association with ID3 126. Affiliated agency system 108 may perform other tasks as needed to configure device 101. Additionally, key.pic associated with ID3 126 may not map the debug lock bits in memory 116, thus preventing users in affiliated agency system 108 from accidentally locking an instance of their own device 101.

[0081] After the configuration of device 101 is completed, the associated institution system 108 may issue ID 4129 to device 101. ID 4129 may be associated with a.pic file such as lock.pic. Lock.pic may be stored in settings 130 on device 101 or elsewhere and define the memory map of memory 116, which does not include the section with the public key written above in (5), nor other sections written by production system 104 or test system 106. Thus, the memory previously used by these systems may subsequently be locked or invisible to the end user of device 101.

[0082] At (7), device 101 may be released to the end user. When using ID 4129, the end user may not be able to see the unmapped portions of memory 116, making these portions unreadable and unwritable. Other memory mapped by ID 4129 may be readable and writable.

[0083] Figure 3 Is an illustration of the memory map of memory 116 for a given different device ID according to an embodiment of the present disclosure. The memory map of memory 116 is shown during four different stages of the security life cycle of system 100 enumerated from (1) to (4). Each such different stage may be associated with a different device ID shown at the bottom. The sections or portions of memory 116 available for programming for a given memory map are shown unshaded. The sections or portions of memory 116 unavailable or unmapped for programming for a given memory map are shown shaded.

[0084] At (1), memory 116 may be within device 101 having ID1 118 as provided by production system 104. ID1 118 may be written to section 117. Device 101 may be within a certain stage of the security life cycle, where device 101 is intended for use within production system 104. Production system 104, which reads ID1 118 and looks it up in its database, may determine the memory map of memory 116 from the resulting.pic file, as shown in (1). Specifically, the memory map may show that the entire memory 116 is available for programming. As described above, production system 104 may write various information or data to memory 116, such as calibration data. This may be stored in section 120. The remainder of memory 116 may not be used by production system 104.

[0085] At (2), the memory 116 can be within the device 101 having ID2 119 in the section 117. The device 101 can be within a certain stage of the security life cycle, where the device 101 is intended to be used within the test system 106. The production system 106 that reads the ID2 119 and looks it up in its database can determine the memory map of the memory 116 from the resulting.pic file, as shown in (2). In one embodiment, as Figure 3 shown, the memory map can show that the section 120 is not available for programming, but the rest of the memory 116 can be used for programming. As described above, the test system 106 can write various information or data to the memory 116, such as keys for internal purposes, such as the factory key represented in the drawings. This can be stored in the section 122. The rest of the memory 116 may not be used by the production system 104.

[0086] At (3), the memory 116 can be within the device 101 having ID3 126 in the section 117. The device 101 can be within a certain stage of the security life cycle, where the device 101 is intended to be used within the affiliated organization system 108. The affiliated organization system 108 that reads the ID3 126 and looks it up in its database can determine the memory map of the memory 116 from the resulting.pic file, as shown in (3). In one embodiment, as Figure 3 shown, the memory map can show that the sections 120 and 122 are not available for programming, but the rest of the memory 116 can be used for programming. As described above, the affiliated organization system 108 can write various information or data to the memory 116, such as keys for internal purposes, such as the affiliated organization key. This can be stored in the section 124. Additionally, as discussed above in the Figure 1 context of, the affiliated organization system 108 can write data for use by the end user of the device 101, such as applications. This can be stored in the section 125. The rest of the memory 116 may not be used by the production system 104.

[0087] At (4), the memory 116 can be within the device 101 having ID4 129 in the section 117. The device 101 can be within a certain stage of the security life cycle, where the device 101 is intended to be used by the end user. Any entity that uses the device, reads the ID4 129, and determines the resulting memory map or views the memory map set on the device 101 can determine the memory map of the memory 116, as shown in (4). In one embodiment, as Figure 3 shown, the memory map can show that the sections 120, 122, and 124 are not available for programming, but the rest of the memory 116 can be used for programming. The entity accessing the device 101 may be able to read data from the section 125 and write to the memory 116 as needed.

[0088] Figure 4 It is a diagram of an exemplary method 400 for providing a security life cycle for a device according to an embodiment of the present disclosure.

[0089] Method 400 can be implemented by any suitable part of the system 100 as shown in Figures 1 to 3 , such as by the device programmer 110. Method 400 can be performed using more or fewer steps than those shown in Figure 4 . In addition, the steps of method 400 can be repeated, omitted, performed in parallel, performed recursively, or performed in a different order than that shown in Figure 4 . Method 400 can be repeated as needed. Method 400 can start at any step, such as at step 405.

[0090] At step 405, a device can be produced. At step 410, an ID can be assigned and added to the device. The memory mapping of the device based on the ID can specify the production phase according to the security life cycle of the device. The memory mapping can define that all areas of the memory can be used for programming.

[0091] At step 415, settings can be made for the device, including programming the memory on the device.

[0092] At step 420, the ID can be changed or replaced with a new ID, and the device can be released to a test or verification system. The memory mapping of the device based on the new ID can specify the test or verification phase according to the security life cycle of the device.

[0093] At step 425, the ID of the device can be read, and the memory mapping of the device can be accessed based on the ID. The memory mapping can be read from a.plc file determined based on the ID. The memory mapping can specify that all areas of the memory other than those previously mapped on the ID in step 410 can be used for programming.

[0094] At step 430, the device can be set based on the available parts identified in the memory mapping, including programming the memory on the device.

[0095] At step 435, the ID can be changed again or replaced with a new ID, and the device can be released to an affiliated institution system. The memory mapping of the device based on the ID of step 435 can specify the affiliated institution customization or completion phase of the product according to the security life cycle of the device.

[0096] At step 440, the ID of the device can be read, and the memory map of the device can be accessed based on that ID. The memory map can be read from a.plc file determined based on the ID. The memory map can specify that all regions of the memory other than those previously mapped on the ID in step 410 or step 425 are available for programming.

[0097] At step 445, the device can be configured based on the available portions identified in the memory map, including programming the memory on the device.

[0098] At step 450, the ID can be changed again or replaced with a new ID, and the device can be released to the end user. The memory map of the device based on the ID of step 450 can specify the stage of use by the end user according to the security life cycle of the device.

[0099] At step 455, the ID of the device can be read, and the memory map of the device can be accessed based on that ID. The memory map can be read from a.plc file determined based on the ID. The memory map can specify that the memory is available for use, except for the regions previously mapped in step 410, 425, or 440.

[0100] At step 460, the available storage space can be used for various tasks of the device.

[0101] Although specific embodiments have been described within this disclosure, those skilled in the art will recognize that certain additions, changes, and variations can be made without departing from the essence and teachings of this disclosure.

Claims

1. An apparatus for tracking the security lifecycle of an embedded device, comprising: A database, the database including a plurality of device profiles; And, A device programmer, the device programmer including instructions that, when read and executed by a processor, cause the device programmer to: Access a first electronic device; Identify a first device identifier of the first electronic device; Based on the first device identifier, access first device data from the database; Based on the first device data, determine a first region of the memory of the first electronic device that can be written to; And Based on the determination of the first region of the memory of the first electronic device that can be written to, write data to the first region of the memory of the first electronic device, Wherein the first device data includes a first memory map of the first device, the first memory map being configured to define a first region of the memory of the first electronic device as programmable.

2. The apparatus according to claim 1, wherein the first memory map is further configured to define a second region of the memory of the first electronic device that cannot be programmed.

3. The apparatus according to claim 2, wherein the first memory map is further configured to define the second region of the memory of the first electronic device as invisible from the use of the first electronic device.

4. The apparatus according to claim 1, wherein the device programmer is further configured to replace the first device identifier with a second device identifier on the first electronic device after writing data to the first region of the memory of the first electronic device.

5. The apparatus according to claim 4, wherein the second device identifier is configured to define a third region of the memory that can be written to.

6. The apparatus according to claim 5, wherein the second device identifier is configured to prevent one or more other devices from writing data to the first region of the memory of the first electronic device.

7. The apparatus according to any one of claims 5 to 6, wherein the second device identifier is associated with a second memory map of the first electronic device, the second memory map being configured to define the third region of the memory of the first electronic device as programmable.

8. The apparatus according to any one of claims 4 to 6, wherein the second device identifier is configured to define that the first region of the memory is not programmable.

9. The apparatus according to any one of claims 4 to 6, wherein the device programmer is further configured to: Identify a third device identifier of a second electronic device; and Based on the third device identifier, determine that a different device programmer rather than the device programmer is configured to write data to the second electronic device.

10. The apparatus according to any one of claims 4 to 6, wherein: The first device identifier is configured to allow access to debug features of the first electronic device through a first memory map; and The second device identifier is configured to deny access to debug features of the first electronic device through a second memory map.

11. A device for tracking the security life cycle of an embedded device, comprising: A database, the database including a plurality of device profiles; And, A device programmer, the device programmer including instructions that, when read and executed by a processor, cause the device programmer to: Access a first electronic device; Identify a first device identifier of the first electronic device; Based on the first device identifier, access first device data from the database; Based on the first device data, determine a first area of the memory of the first electronic device that can be written to; And Based on the determination of the first area of the memory of the first electronic device that can be written to, write data to the first area of the memory of the first electronic device, After writing data to the first area of the memory of the first electronic device, replace the first device identifier with a second device identifier on the first electronic device.

12. The device according to claim 11, wherein the first device data includes a first memory map of the first device, the first memory map being configured to define the first area of the memory of the first electronic device as programmable.

13. The device according to claim 12, wherein the first memory map is further configured to define a second area of the memory of the first electronic device that cannot be programmed.

14. The device according to claim 13, wherein the first memory map is further configured to define the second area of the memory of the first electronic device as invisible from the use of the first electronic device.

15. The device according to claim 11, wherein the second device identifier is configured to define a third area of the memory that can be written to.

16. The device according to claim 15, wherein the second device identifier is configured to prevent one or more other devices from writing data to the first area of the memory of the first electronic device.

17. The device according to any one of claims 15 to 16, wherein the second device identifier is associated with a second memory map of the first electronic device, the second memory map being configured to define the third area of the memory of the first electronic device as programmable.

18. The device according to any one of claims 14 to 16, wherein the second device identifier is configured to define that the first area of the memory is not programmable.

19. The device according to any one of claims 14 to 16, wherein the device programmer is further configured to: Identify a third device identifier of a second electronic device; and Based on the third device identifier, determine that a different device programmer rather than the device programmer is configured to write data to the second electronic device.

20. The device according to any one of claims 14 to 16, wherein: The first device identifier is configured to allow access to debug features of the first electronic device through the first memory map; and The second device identifier is configured to deny access to debug features of the first electronic device via a second memory mapping.

21. An apparatus for tracking the security life cycle of an embedded device, comprising: a memory; and a device programmer including instructions which, when read and executed by a processor, cause the device programmer to: provide access to a first electronic device for the device programmer; provide a first device identifier from the memory to the device programmer; and based on the first device identifier: represent a production stage of the apparatus; and permit access to a first writable region of the memory; wherein the first device identifier is replaced by a second device identifier.

22. The apparatus according to claim 21, wherein the first device identifier is configured to prevent programming of a second region of the memory.

23. The apparatus according to claim 22, wherein the second region of the memory is not mapped for use by the apparatus.

24. The apparatus according to claim 21, wherein the second device identifier is configured to define a third writable region of the memory.

25. The apparatus according to claim 24, wherein the second device identifier is further configured to prevent writing data to the first region of the memory.

26. The apparatus according to any one of claims 24 to 25, wherein the second device identifier is further configured to define that the first region of the memory is not programmable.

27. The apparatus according to any one of claims 24 to 25, wherein: the first device identifier is configured to permit access to debug features of the apparatus via a first memory mapping; and the second device identifier is configured to deny access to debug features of the apparatus via a second memory mapping.

28. A method for tracking the security life cycle of an embedded device, the method comprising operating according to any one of the apparatuses of claims 1 to 10.

29. A method for tracking the security life cycle of an embedded device, the method comprising operating according to any one of the apparatuses of claims 11 to 20.

30. A method for tracking the security life cycle of an embedded device, the method comprising operating according to any one of the apparatuses of claims 21 to 27.

Images