Method and system for secure and controlled unlocking of device functions

Abstract

A method and system for controlling access to restricted functions of computing devices are provided. [Solution] The method includes the steps of: receiving an access request to a restricted function (125) of a computing device (100) that identifies at least a portion of the restricted function (125) to be unlocked; sending the request to a trusted license store (140); receiving data indicating a license that includes an identifier of a portion of the restricted function and the number of times the user may access the restricted function; determining that the user has not accessed the restricted function more times than the number of times the user may access it; and providing access to the restricted function in response to the determination that the user has not accessed the restricted function (125) more times than the number of times the user may access it.

Description

Technical Field

[0001] The present disclosure generally relates to providing secure access to restricted device functionality. In particular, aspects of the present disclosure enable access to functionality on a locked computing device whose full functionality is otherwise restricted.

Background Art

[0002] Many computing devices, such as controllers used in various electronic devices and other devices, execute authorized binary files signed by a signing authority to ensure that the computing device executes only the binaries and configurations required by the computing device to perform its functions. However, there are certain cases where it is necessary to relax restrictions on the functionality of a computing device, such as authorizing a returned product (returning the controller to the factory for diagnosis or repair) or developing software for a computing device, enabling functions that are not normally required and may not be desirable under normal secure operation.

[0003] Generally, to restrict access to this functionality, the private key administrator needs to restrict access to the signed software image or version that enables security-sensitive functionality. However, it can be difficult to prevent leakage of the signed software image if it is necessary to share the signed image with a third party. Such leakage makes security-sensitive functionality more widely available to third parties.

Summary of the Invention

[0004] Aspects and advantages of the systems and methods according to the present disclosure may be described in part in the following description, or may become apparent from the description, or may be learned through practice of the technology.

[0005] According to one embodiment, a method is provided. The method includes the step of receiving a request from a user for access to restricted functions of a computing device by one or more electronic processors, wherein the access request identifies at least a portion of the restricted functions of the computing device to be unlocked for access by the user. The method also includes the step of sending a request to a trusted license store by one or more electronic processors, and the step of receiving license-indicating data from the trusted license store by one or more electronic processors, wherein the license-indicating data includes identifiers of the portion of the restricted functions to be unlocked for access and the number of times the user may access the restricted functions. The method may further include the step of determining by one or more electronic processors that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions. The method also includes the step of providing the user with access to the restricted functions by one or more electronic processors in response to determining that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions.

[0006] According to another embodiment, a computing device is provided. The computing device may include one or more processors and a non-temporary computer-readable medium containing instructions that cause one or more processors to perform an operation when executed by the one or more processors. An operation may include receiving a request from a user to access restricted functions of the computing device, wherein the access request identifies at least some of the restricted functions of the computing device to be unlocked for user access. The operation may also include sending a request to a trusted license store and receiving license-indicating data from the trusted license store, wherein the license-indicating data includes identifiers of some of the restricted functions to be unlocked for access and the number of times the user may access the restricted functions. The operation may further include determining that the user has not accessed the restricted functions more times than the number of times the user may access them. The operation may also include providing the user with access to the restricted functions in response to determining that the user has not accessed the restricted functions more times than the number of times the user may access them.

[0007] In a further embodiment, a non-temporary computer-readable medium is provided. The non-temporary computer-readable medium may, when executed by one or more processors, include instructions causing one or more processors to perform an action. The action may include receiving a request from a user for access to restricted functions of a computing device, wherein the access request identifies at least some of the restricted functions of the computing device to be unlocked for user access. The action may also include sending a request to a trusted license store and receiving license-indicating data from the trusted license store, wherein the license-indicating data includes identifiers of some of the restricted functions to be unlocked for access and the number of times the user may access the restricted functions. The action may further include determining that the user has not accessed the restricted functions more times than the number of times the user may access them. The action may also include providing the user with access to the restricted functions in response to determining that the user has not accessed the restricted functions more times than the number of times the user may access them.

[0008] These and other features, aspects and advantages of the Method and System will be better understood by referring to the following description and the appended claims. The appended drawings, which are incorporated herein and constitute part of this specification, illustrate embodiments of the Art and, together with the description in the specification, are useful in illustrating the principles of the Art.

[0009] A complete and implementable disclosure of the System and Method, including the best modes of construction and use of the System and Method, intended for those skilled in the art, is described herein with reference to the attached figures. [Brief explanation of the drawing]

[0010] [Figure 1]A block diagram of a computing device according to an embodiment of the disclosure is shown. [Figure 2] This figure shows an exemplary mutual authentication network connection according to an embodiment of the disclosure. [Figure 3] This figure shows two-factor authentication according to the present disclosure embodiment. [Figure 4A] This figure shows a computing device that receives a one-way unlock operation according to an embodiment of the present disclosure. [Figure 4B] This figure shows the secure boot function according to the embodiment of this disclosure. [Figure 5] This flowchart shows a method for controlling access to restricted functions of a computing device according to embodiments of the present disclosure. [Modes for carrying out the invention]

[0011] Embodiments of the Method and System are described in detail hereby shown in the drawings, with one or more examples being illustrated. Each example is provided for illustrative purposes of the Art and is not intended to limit the Art. In fact, it will be apparent to those skilled in the art that modifications and changes can be made in the Art without departing from the scope or spirit of the claimed Art. For example, features illustrated or described as part of one embodiment can be used in conjunction with another embodiment to bring about further embodiments. Thus, this disclosure is intended to encompass modifications and changes that fall within the scope of the appended claims and their equivalents.

[0012] Figure 1 is a block diagram showing a computing device 100 according to an embodiment of the present disclosure. In some embodiments, the computing device 100 may be an electronic controller used to control one or more electronic devices such as electrical equipment or industrial machinery. In other embodiments, the computing device 100 may be a personal computing device such as a laptop, smartphone, tablet, or smart wearable. In further embodiments, the computing device 100 may be a server or other computing system.

[0013] The computing device 100 may include one or more processors 105, an input-output interface 110, a human-machine interface 115, and memory 120.

[0014] One or more processors 105 may be one or more electronic processors such as a microprocessor, a programmable logic controller ("PLC"), or a field-programmable gate array ("FPGA"). One or more processors 105 may, among other things, be configured to read and execute instructions in order to carry out one or more methods described herein.

[0015] The input-output interface 110 can enable the computing device 100 to communicate with other computing devices, peripheral devices, computing networks, etc. For example, the input-output interface 110 may include one or more interfaces for conducting wired or wireless communication with another computing device via one or more computing networks.

[0016] The human-machine interface 115 can enable a user to interact with the computing device 100. In some embodiments, the human-machine interface 115 may include one or more interfaces that display information to the user, such as a display screen, and may also include one or more interfaces that enable the user to interact with the information displayed on the screen, such as a touchscreen component, a mouse component, a keyboard component, a stylus component.

[0017] Memory 120 may include one or more non-temporary computer-readable memories, such as random access memory ("RAM"), hard drives, solid-state drives, and other forms of computer memory. Memory 120 may store instructions 121 that cause one or more processors 105 to perform operations, including operations related to the methods described herein, when executed by one or more processors 105. Memory 120 may also store data 122 related to the operation of the computing device 100.

[0018] Memory 120 can also store restricted functions 125. In other words, during normal operation of the computing device 100, such as when the computing device 100 is running a software image 130 or a particular version of the software available, certain functions available to the computing device 100 may be “locked” so that access is restricted or unavailable. Restricted functions 125 may include, for example, access to development or management commands for the computing device 100, access to the root functions of the computing device 100, access to restricted and / or private data of the computing device 100, enabling the execution of one or more binary files outside the scope of the software image 130, or modifying one or more configuration files of the computing device 100. Thus, in a production environment where the running software image 130 is production software, such as on a controller of industrial machinery or electronic equipment that performs its intended function, access to restricted functions 125 by users of the computing device 100 can be locked.

[0019] However, there are times when access to the restricted features 125 of computing device 100 is necessary, such as when performing diagnostics on computing device 100 or when testing a new version of software image 130 before shipping a new version of software image 130. To allow access to the restricted features 125 only to authorized individuals and to deny access to unauthorized individuals without compromising the operational security of computing device 100, a signed software license file can be generated. The software license file is a file generated to provide the user with a set of rights regarding the software, including granting access to the restricted features 125. The software license may include public information such as access control information indicating the type, version, image, or build of the software that the license holder is permitted to access, which is checked when the user attempts to access the restricted features 125 to verify that the user is entitled to access the restricted features 125.

[0020] A software license may include a binary file to be executed on computing device 100, identification information (such as a cryptographic hash) for the binary file to be executed, an identifier for the portion of restricted functionality 125 that is unlocked for access, identification information for the user who is enabled to access the restricted functionality 125, and the number of times the user can access the restricted functionality 125. The binary file to be executed may be, for example, a software image 130 used to test on computing device 100, a diagnostic application to be executed on computing device 100, or another software application to be executed on computing device 100 and perform other restricted functions on computing device 100. In some embodiments, the execution of the binary file restricts the functionality of computing device 100 to the operation of a single computing application that gives user access to only a portion of the restricted functionality 125. In other embodiments, the execution of the binary file includes giving the user access to a shell or command-line interpreter, a program that enables the user to access a limited set of tools and actions restricted by one or more access controls. The set of tools and actions allows the user to interact with a portion of the restricted functionality 125 without enabling free access to the entire restricted functionality 125.

[0021] User identification information can be obtained based on the logged-in user on the computing device 100, for example, by a user who self-identifies by receiving a public key associated with a specific user via user input, or by swiping a smart card associated with the user. By verifying user identification information, access to some of the restricted functions 125 is granted only to identified users, in order to ensure the security of the computing device 100.

[0022] The number of times a user is allowed to access the restricted function 125 is set to prevent malicious actors from accessing non-production versions of the software and / or the restricted function 125. This helps prevent third parties given access to a computing device, such as computing device 100, from exceeding the permitted access limitations of computing device 100. In some embodiments, when a user accesses the restricted function 125 using a signed software license, computing device 100 can determine that the user has not yet accessed the restricted function 125 more times than defined by the signed software license. In some embodiments, computing device 100 can perform this determination by comparing the value stored in monotonic counter 135 of computing device 100 with the number of times the user can access the restricted function 125. The monotonic counter is a hardware-implemented counter that can store a value equal to the number of times the user has accessed the restricted function 125. When the user accesses the restricted function, monotonic counter 135 can increment. If the value stored in monotonic counter 135 is greater than the number of times the user can access the restricted function 125, access to the restricted function 125 by the user can be locked out, thus preventing the user from exceeding the limitations of the signed software license.

[0023] In some embodiments, the signed software license may also include a unique identifier for computing device 100. The unique identifier for computing device 100 may include at least one of the unique serial number of computing device 100 and a unique public key associated with computing device 100. Including a unique identifier for computing device 100 in the signed software license may be advantageous in ensuring that the signed software license cannot be applied to any computing device other than the specific computing device 100, and thus guaranteeing greater security for accessing restricted functions of other computing devices.

[0024] In some embodiments, the signed software license may further include a unique identifier for the computing device 100, which includes at least one of a unique serial number for a component of the computing device 100 and a unique public key associated with that component. In these embodiments, the signed software license uses the unique identifier of the component to identify the entire computing device 100 (the TPM - Trusted Platform Module as the identified component).

[0025] A signed software license can be obtained from a license authority computing system. In some embodiments, the memory 120 can store a trust store 140. The trust store 140 stores trusted certificates used to authenticate licenses that enable access to the computing device 100. In some embodiments, the trust store 140 can be a software application and / or data repository stored in the computing device 100 that includes a public key that can be used to authenticate a license file provided to the computing device 100 by a user, and the license file is signed with a private key associated with one or more of the public keys stored in the trust store 140.

[0026] In another embodiment, a software license can be obtained from a remote computing system such as a trusted license server via a secure mutual authentication network connection via a mutual authentication network connector 145. An example of this network connection is shown in FIG. 2A.

[0027] The mutual authentication network connector 145 of the computing device 100 can send a request to the trusted license server 200 to obtain a license. In some embodiments, the request can include identification information of the user sending the request, identification information of the provided license, identification information of the portion of the restricted function 125 that access is requested to, identification information of the computing device 100, etc. The request can also include key exchange information for mutual authentication.

[0028] The trusted license server 200 can receive requests at the second mutual authentication network connector 205. The second mutual authentication network connector 205 verifies the identity information of the computing device 100 and / or the user of the computing device 100, while the mutual authentication network connector 145 simultaneously authenticates the identity information of the trusted license server 200. In some embodiments, key exchange information can be used to enable both the trusted license server 200 and the computing device 100 to establish a shared key used to secure subsequent communications. Once the identity information is mutually verified, a secure connection is established between the computing device 100 and the trusted license server 200 via the secured communication network 250.

[0029] The trusted license server 200 may also include a license store 210 that can store license information. In response to receiving a request from the mutual authentication network connector 145, the trusted license server 200 can access the license store 210 to retrieve the appropriate license information based on the details sent in the request. The trusted license server 200 can then transmit the retrieved license information to the computing device 100 via the secure communication network 250.

[0030] Returning to Figure 1, the computing device may also include a two-factor authentication system 150. In addition to requiring an appropriate license to access the restricted features 125, the user may also be required to complete two-factor authentication via the two-factor authentication system 150 before fully accessing some of the restricted features 125. An example of two-factor authentication is shown in Figure 3.

[0031] The computing device 100 can generate a two-factor authentication request using the two-factor authentication system 150. The request may include an identifier for the user submitting the request, an identifier for the computing device 100, an identifier for the restricted function 125, and so on.

[0032] In some embodiments, the computing device 100 may include a smart card reader 175. The smart card reader 175 can read data from a smart card, such as a hardware authentication device that stores a private key, which can be used to authenticate a user in a manner similar to mutual authentication to a trusted license store 140. For example, a smart card can be inserted into the computing device 100 using the smart card reader 175 (e.g., by inserting the smart card into a universal serial bus port, etc.) and read by the smart card reader 175 to identify the private key stored on the smart card. The smart card reader 175 can retrieve a public key from memory 120 that can be used in a challenge-response protocol with the private key stored on the smart card to authenticate the user.

[0033] The request can be sent by the two-factor authentication system 150 to a request handler 305 of a remote computing system, such as a two-factor authentication server 300, via the secure communication network 350. The request handler 305 receives the generated request. In some embodiments, the request handler 305 can access the user data store 320 to determine whether the user who sent the request is a registered user for two-factor authentication, and in some embodiments, it can obtain means for sending an authentication message to the user, such as an email address or telephone number associated with the user.

[0034] After the means for sending an authentication message to the user is obtained from the user data store 320, the two-factor authentication server 300 can use the code generator 310 to generate an authentication code. The authentication code can then be sent to the user by the two-factor authentication server via the secure communication network 350, through means of communication with the user such as email or text message, and then sent to the authentication device 375.

[0035] The user can receive a code on the authentication device 375 and, in some embodiments, enter the code into the authentication application 380. The authentication application 380 sends the code back to the two-factor authentication server 300 via the secure communication network 350.

[0036] The two-factor authentication server 300 can receive a code from the authentication device 375 and use the code authentication unit 315 to verify that the code is the same code that was sent to the authentication device 375. If the two codes do not match, the user is not authorized and therefore denied access to the restricted function 125 of the computing device 100. If the codes match, the two-factor authentication server 300 generates an authentication confirmation and sends it to the two-factor authentication system 150. In response to receiving the authentication confirmation, the two-factor authentication system 150 can enable access to the restricted function 125 of the computing device, such as enabling the execution of a binary file associated with the restricted function 125.

[0037] In another embodiment, instead of sending requests over a secure communication network, the computing device 100 can be electronically coupled with a two-factor authentication device (e.g., using a physical code) to ensure the security of two-factor authentication. In this embodiment, the authentication device can be a hardware authentication device that can support, for example, a one-time password, a public key, etc., to authenticate that the user of the hardware authentication device has been granted access to the computing device 100.

[0038] Memory 120 may also include a secure boot function 155. The secure boot function 155 may include data values ​​that control the desired behavior of the computing device 100 during startup or "booting". When the computing device 100 is turned on, the secure boot function 155 can be executed as part of the startup process. The secure boot function 155 can be used to securely load a software image, such as a software image 130, and to verify that the software image 130 can be booted and run on the computing device 100. An example of the secure boot function 155 is shown by process 400 in Figure 4A.

[0039] In block 402, process 400 may include determining the signature associated with software image 130 based on the private key associated with software image 130. For example, when a version of software image 130 is created, the private key can be used to sign the version of software image 130, thereby indicating that the version of software image 130 is from a trusted source that has access to the private key. The version of software image 130 can then be deployed to a computing device such as computing device 100.

[0040] During the boot-up of computing device 100, the signature associated with the software image 130 can be accessed by computing device 100. This signature may include data that identifies the private key, such as data encrypted with the private key.

[0041] To create a signature, a hash value associated with the software image 130 can be calculated, the resulting hash value can be encrypted with a private key, and finally a digital signature is created. This signature can be encrypted using one or more cryptographic algorithms, such as the Rivest Shamir Adleman ("RSA") cryptographic algorithm, the Elliptic Curve Digital Signature Algorithm ("ECDSA") cryptographic algorithm, or another suitable cryptographic algorithm. The created digital signature can then be attached to or embedded in the software image 130, along with a public key for use in subsequent signature verification on the computing device 100.

[0042] When computing device 100 boots up, the public key is obtained from software image 130, and then hashed to obtain the public key hash value.

[0043] In block 404, process 400 may include comparing the public key hash value with programmed hash values ​​stored in a first set of fuses 160.

[0044] When the computing device 100 is provisioned, a public key hash value can be programmed into a first set of fuses 160. To program the public key hash value, the computing device 100 can receive a public key associated with a private key used to sign a software image 130 that may be received by the computing device 100. The public key hash value can be generated based on the public key. This public key hash value can then be programmed into the first set of fuses 160 by generating a combination of values ​​that will be set as voltage values ​​in the first set of fuses 160, for example.

[0045] In some embodiments, a first set of fuses 160 may store a security version number ("SVN"). The SVN may be a value determined using a value other than the public-private key pair used to sign the software image 130. For example, the manufacturer of the software image 130 may create different versions of the software image 130 for distribution, while maintaining the same SVN for each version of the software image 130. This SVN value may be stored as a programmed value stored in the first set of fuses 160. In these embodiments, instead of comparing signatures made using the private key associated with the software image 130, the computing device 100 may compare the SVN of the software image 130 with the SVN value stored in the first set of fuses 160 for the purpose of determining whether the software image 130 is valid. In some embodiments, the first set of fuses 160 may store a public key hash for use during the operation of the secure boot function 155, and different sets of fuses may store SVNs. During the operation of Secure Boot feature 155, the public key hash value may always be required, and in addition to comparing the public key hash with the signature, SVN can be used.

[0046] In some embodiments, signature checking is required, so the use of a public key for verification is always required for the secure boot function 155. In these embodiments, the SVN may be used in addition to the public key for the purpose of protecting against rollback attacks and is therefore stored in a set of fuses that are not associated with the stored public key value. Furthermore, instead of storing the hash value of the SVN, these separate fuses store the SVN value itself.

[0047] In block 406, process 400 may use the output of a verification algorithm to determine whether the software image 130 passes verification. For example, if the public key hash value associated with the software image 130 matches the public key hash values ​​programmed into the first set of fuses 160, the public key is determined to be a trustworthy public key. The signature of the software image 130 can then be verified by using the public key to create a new hash of the software image 130, for example, and comparing the new hash with the decrypted signature. If the new hash and the decrypted signature match, the software image 130 can be determined to be a valid software image.

[0048] In block 408, if the software image 130 fails verification, the computing device 100 will not allow booting up using the software image 130. In some embodiments, the computing device 100 may immediately reboot in response to the invalidity of the software image 130, thereby causing the computing device 100 to enter a "reboot loop" if a valid software image 130 is not provided to the computing device 100. In another embodiment, if the software image 130 is invalid, the computing device 100 may be prevented from fully booting by turning off the computing device 100 or disabling access to any function of the computing device 100 except for the ability to provide the computing device 100 with a new software image 130 for reverification.

[0049] In block 410, if the software image 130 passes verification, the computing device 100 can continue booting up using the software image 130, which may include installing the software image 130 on the computing device 100 to enable the computing device 100 to interact with the functions of the software image 130.

[0050] In another embodiment, the secure boot function 155 may include a verification process that compares different hash values ​​stored in different sets of fuses, such as a first set of fuses 160 or a second set of fuses 165, such as the process 450 shown in Figure 4B.

[0051] In block 452, process 450 may include identifying the signature associated with software image 130. When a version of software image 130 is created, the version of software image 130 can be signed using a private key, thereby indicating that the version of software image 130 is from a trusted source that has access to the private key. To sign software image 130, the signer of software image 130 may hash software image 130 and encrypt the hashed software image 130 using the private key. The encrypted result of this process can be the signature of software image 130. The encrypted result of the hash of software image 130 can then be deployed to a computing device such as computing device 100.

[0052] To identify the signature, the computing device 100 can access the software image 130 and identify the public key and the signature stored with the software image 130.

[0053] In block 454, process 450 may include determining a programmed hash value based on the value of the switch fuse 170 for comparison with a hashed public key value obtained from the software image 130.

[0054] To determine the programmed hash value, the identified public key in the signature of software image 130 can be hashed using a hashing algorithm.

[0055] In some embodiments, the switch fuse 170 can be set to a value that indicates how verification should be performed and what value should be used to carry out the verification. In one example, the switch fuse 170 can be set to one of three possible values: 0, 1, or 2. Each value can indicate a different process and / or a different value used to verify the software image 130. For example, in block 456, if the switch fuse 170 has a value of 0, no further verification steps are required, and the computing device 100 can proceed with booting up using the software image 130 as is, without any additional control on the software image 130.

[0056] In some embodiments, the switch fuse 170 can be set to a value of 1. In block 458, if the switch fuse 170 is set to a value of 1, process 450 can access a public key hash value programmed as a programmed hash value in the first set of fuses 160. In some embodiments, the first set of fuses 160 can be considered a “primary” fuse, which may indicate that the programmed hash value in the first set of fuses 160 may be a public key hash value associated with a software image, which is a production software image or another less acceptable software image. Since the production software image may be designed to operate in real-world scenarios, such as a factory controller or an electrical equipment controller, the production software image may have limited access to restricted functions of the computing device, such as not being given access to restricted functions 125. The production software image does not need to access the more restricted functions of the computing device 100 while operating in a real-world scenario.

[0057] In some embodiments, the switch fuse 170 can be set to a value of 2. In block 460, if the switch fuse 170 is set to a value of 2, process 450 can access a public key hash value programmed as a programmed hash value in a second set of fuses 165. In some embodiments, the second set of fuses 165 can be considered a "backup" fuse, which may indicate that the programmed hash value in the second set of fuses may be a public key hash value associated with a test software image or other more permissible software image. These more permissible software images may allow the user to access more functionality of computing device 100 and / or software image 130 for testing or troubleshooting purposes.

[0058] Regardless of whether the programmed hash value is selected from a first set of fuses 160 or a second set of fuses 165, in block 462, the selected programmed hash value is compared with the public key hash value determined based on the public key of the software image 130.

[0059] In block 464, process 450 may include using the output of the verification algorithm to determine whether the software image 130 passes verification.

[0060] In block 466, if the software image 130 fails verification, the computing device 100 will not allow booting up using the software image 130. In some embodiments, the computing device 100 may immediately reboot in response to the invalidity of the software image 130, thereby causing the computing device 100 to enter a "reboot loop" if a valid software image 130 is not provided to the computing device 100. In another embodiment, if the software image 130 is invalid, the computing device 100 may be prevented from fully booting by turning off the computing device 100 or disabling access to any function of the computing device 100 except for the ability to provide the computing device 100 with a new software image 130 for reverification.

[0061] In block 468, if the software image 130 passes verification, the computing device 100 may continue booting up using the software image 130, which may include loading or installing the software image 130 into the computing device 100 to enable the computing device 100 to interact with the functions of the software image 130.

[0062] In some embodiments, the programmed hash value associated with the SVN can be stored in one or more separate banks of fuses other than the first set of fuses 160 or the second set of fuses 165. The SVN can be a value determined using a value other than the public-private key pair used to sign the software image 130. For example, the manufacturer of the software image 130 can create different versions of the software image 130 for distribution while maintaining the same SVN for each version of the software image 130. This SVN value can be stored as a programmed value in one or more separate sets of fuses. In these embodiments, instead of comparing signatures made using the private key associated with the software image 130, the computing device 100 can compare the value associated with the SVN of the software image 130 with the SVN value stored in the separate set of fuses for the purpose of determining whether the software image 130 is valid.

[0063] The switch fuse 170 may be intended to have more or fewer values ​​associated with controlling which verification steps are performed and which verification values ​​are used. Furthermore, the values ​​that can be stored in the switch fuse 170 may not be values ​​other than 0, 1, or 2, but rather may be intended to be any appropriate value that can be used to guide the process 450 along the correct verification path.

[0064] In some embodiments, the secure boot function 155 can track the number of times a user accesses restricted functionality 125. For example, when computing device 100 verifies software image 130, a monotonic counter, such as monotonic counter 135, can be incremented to indicate that software image 130 has been verified. The value of monotonic counter 135 can then be compared to the number of times access to restricted functionality 125 is permitted, as indicated by the signature of software image 130. If the value of monotonic counter 135 exceeds the limit, computing device 100 may deny access to the restricted functionality by software image 130, even if software image 130 has been verified in other ways.

[0065] In some embodiments, a switch fuse 170 can be used to protect against rollback attacks. A rollback attack involves intentionally using an earlier version of software, such as a software image 130, to attempt to access restricted functionality 125 of the computing device 100. This type of attack attempts to exploit security vulnerabilities that may exist in the earlier software image and / or to use a private key that has been leaked to the public.

[0066] By utilizing the switch fuse 170, different public key hash values ​​can be stored in the computing device 100, thereby providing the manufacturer with a secondary option (e.g., a "backup" second set of fuses 165) for securely verifying and booting the software image on the computing device 100, even if the private key of the software image is leaked or the software image is compromised for any other reason. The manufacturer of the computing device 100 can "burn" or otherwise irrevocably change the value stored in the switch fuse 170 to prevent the leaked information (private key or software image) from being verifiable on the computing device 100.

[0067] As described above, "burning" the value stored in the switch fuse 170 means irrevocably changing the value stored in the switch fuse 170. For example, in one embodiment, a voltage can be driven into the switch fuse 170 to change the value stored in the switch fuse 170, thereby physically changing the switch fuse 170 so that it cannot be returned to a previously stored value. In another embodiment, special software can be used to access and change the digital value stored in the switch fuse 170, and then a "lock" can be applied against returning to the previous value, such as by incrementing a monotonic counter associated with the switch fuse 170. This results in a "one-way" unlock of the computing device 100, as the computing device 100 can never access the value of the set of fuses indicated by the switch fuse 170 before the value of the switch fuse 170 was changed.

[0068] In some embodiments, the switch fuse 170 can be set to a value that does not require further verification if the computing device 100 is under development, testing, or used only in a test, development, or diagnostic environment, and the computing device 100 is under the sole control of the manufacturer of the computing device 100 and / or the manufacturer of the software image 130. These environments can be considered more secure because the computing device 100 is under the physical control of the manufacturer and therefore the risk of attack is much lower. Due to this inherent security, the switch fuse 170 can be set to zero or another appropriate value to enable boot-up with the software image 130 without requiring extra verification. This allows the developers or testers of the computing device 100 and / or the software image 130 to implement rapidly changing versions of the software image 130 for development and testing without needing to verify the software image 130.

[0069] After development and / or test use of computing device 100 is complete and computing device 100 is ready for production use, the switch fuse 170 can be "burned" to eliminate values ​​that do not require verification. The value of switch fuse 170 can be set to a value that requires verification for production use instead, such as the "1" value described above. If a user attempts to boot up computing device 100 while switch fuse 170 is set to this value, the software image 130 is accessed to identify the public key hash value or public key, the public key is hashed to generate a hash value, which is then compared to the programmed hash values ​​of the set of fuses of computing device 100 (e.g., fuse 160 of the first set), as described above.

[0070] In some embodiments, the programmed hash value in the first set of fuses 160 can also be set to an initial SVN value by "burning" the switch fuse 170. This SVN value can be set by the user "burning" the switch fuse 170 to match or be less than the current SVN value associated with an acceptable software image, thereby allowing the software image to pass verification, while older software images with lower SVN values ​​will fail verification, ensuring the prevention of rollback attacks. Since the SVN value increases with newer versions of the software image 130, the value of this fuse can be incremented to reflect newer valid software images and avoid verifying older software images with lower SVN values.

[0071] If the computing device 100 or the value of the private key is compromised or malfunctions, the switch fuse 170 can be "burned" again by irrevocably changing the value from the current value to a new value, such as changing the value from "1" to "2". This new value can point to a different public key hash value stored in a different set of fuses, such as a second set of fuses 165. In some embodiments, the second set of fuses 165 can store an SVN with a lower SVN value than the first set of fuses 160, allowing an older software image with a lower SVN value to be booted on the computing device 100 for testing or diagnostic purposes.

[0072] The computing device 100 can also store credentials 180 in data 122. The identification credentials 180 can uniquely identify the computing device 100 for the purpose of obtaining licenses for different versions of the software image 130. In some embodiments, the identification credentials 180 can be a secret key associated with a trusted license.

[0073] In some embodiments, if the computing device 100 is compromised, the credentials 180 may be deleted or otherwise destroyed by the computing device 100, preventing the computing device 100 from accessing a license for a valid software image. In another embodiment, a certification authority managing the license associated with the credentials 180 may revoke the license, preventing the credentials 180 from being used to access any valid software image. In some embodiments, if the credentials 180 are deleted, destroyed, or revoked, the computing device 100 may be configured to no longer be able to boot any software image or to fail any verification of any software image.

[0074] Figure 5 is a flowchart illustrating a method 500 for controlling access to restricted functions of a computing device according to an embodiment of the present disclosure.

[0075] In block 502, method 500 may include the step of receiving an access request from a user for restricted functions of a computing device by one or more electronic processors, the access request identifying at least a portion of the restricted functions of the computing device to be unlocked for access by the user.

[0076] In block 504, method 500 may include the step of sending a request to a trusted license store by one or more electronic processors.

[0077] In some embodiments, method 500 may further include the step of sending a request to a trusted license store by establishing a secure mutual authentication network connection to a trusted license server.

[0078] In some embodiments, the step of sending the request to the licensing authority computing system may include providing the request to the digital signature authority.

[0079] In block 506, method 500 may include the step of receiving a signed license from a license authority computing system by one or more electronic processors, the signed license including a binary file to be executed on a computing device, identifiers of some of the restricted functions to be unlocked for access, user identification information, and the number of times the user may access the restricted functions.

[0080] In some embodiments, method 500 may further include the step of receiving a signed license from a trusted license server via a mutual authentication network connection.

[0081] In some embodiments, the step of receiving a signed license may include a digital signature authority granting a signed license.

[0082] In some embodiments, the signed license may also include a unique identifier for the computing device. The unique identifier for the computing device may include at least one of the computing device's unique serial number and the unique public key associated with the computing device.

[0083] In some embodiments, the signed license may include a unique identifier for the computing device. The unique identifier for the computing device may include at least one of the unique serial number of a component of the computing device and a unique public key associated with a component of the computing device.

[0084] In some embodiments, the signed license grants access only to components identified by a unique serial number or a unique public key.

[0085] In block 508, method 500 may include the step of determining, by one or more electronic processors, that the user has not accessed the restricted function more times than the number of times the user is entitled to access the restricted function.

[0086] In some embodiments, in response to determining that the user has not accessed the restricted functionality more times than permitted, Method 500 may further include the step of sending a two-factor authentication message to a remote computing device by one or more electronic processors. Method 500 may also include the step of receiving a two-factor authentication confirmation from a two-factor authentication computing system by one or more electronic processors.

[0087] In some embodiments, in response to receiving two-factor authentication confirmation, method 500 may include the step of enabling the execution of a binary file by one or more electronic processors.

[0088] In some embodiments, the step of sending a two-factor authentication message to a remote computing device can be initiated in response to the user presenting a smart card that identifies the user on a computing device.

[0089] In some embodiments, the step of determining whether a user has accessed a restricted function more times than the number of times the user is allowed to access the restricted function may include one or more electronic processors comparing the number of times the user is allowed to access the restricted function with a counter on a computing device, and one or more electronic processors determining whether the counter has a value less than or equal to the number of times the user is allowed to access the restricted function.

[0090] In block 510, method 500 may include the step of executing a binary file on a computing device by one or more electronic processors in response to determining that the user has not accessed the restricted functionality more times than the number of times the user is entitled to access the restricted functionality, the step of executing the binary file may include enabling access to a portion of the restricted functionality of the computing device identified by the signed license.

[0091] In some embodiments, method 500 may further include the step of incrementing a counter on a computing device in response to the execution of a binary file.

[0092] In some embodiments, the counter can be a hardware-protected monotonic counter.

[0093] In some embodiments, method 500 may further include a step of verifying a signed license, which may include determining by one or more electronic processors that the license exists, is authentic, and is intact by verifying the signature or source of the signed license.

[0094] In some embodiments, the step of executing a binary file on a computing device to enable access to some of the restricted functions may include enabling one or more electronic processors to execute a single software application that permits a limited set of operations for the computing device.

[0095] In some embodiments, the step of executing a binary file on a computing device to enable access to some of the restricted functions may include enabling one or more electronic processors to access a shell having a limited set of tools and actions, and access to the shell is limited by one or more access controls.

[0096] The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” Any implementation described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to other implementations. Furthermore, unless specifically identified, all embodiments described herein should be considered illustrative.

[0097] In the detailed description, numerals and letters are used to refer to features of the drawings. Similar or identical reference numerals in the drawings and description are used to refer to similar or identical parts of the invention. As used herein, the terms “first,” “second,” and “third” may be used interchangeably to distinguish one component from another and are not intended to indicate the location or importance of any individual component.

[0098] Approximation terms such as "about," "approximately," "roughly," and "substantially" are not limited to specified exact values. In at least some cases, approximation language may correspond to the precision of an instrument used to measure a value, or the precision of a method or machine used to construct or manufacture a component and / or system. For example, approximation language may refer to any individual value, range of values, and / or endpoints defining a range of values ​​being within a margin of 1, 2, 4, 5, 10, 15, or 20 percent.

[0099] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, article, or apparatus that includes an enumeration of features is not necessarily limited to those features alone, but may include other features not expressly enumerated, or other features specific to such process, method, article, or apparatus. Furthermore, unless expressly stated otherwise, “or” refers to an inclusive OR, not an exclusive OR. For example, condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0100] Here, and throughout the entirety of the specification and claims, limitations on scope are combined and replaced, and unless the context and wording specifically indicate otherwise, such scope is identified and includes all sub-scopes contained therein. For example, all scopes disclosed herein include endpoints, which are independently combinable with respect to one another.

[0101] This specification uses examples to disclose the invention in its best mode and to enable any person skilled in the art to practice the invention, including the fabrication and use of any device or system and the implementation of any method incorporating it. The patentable scope of the invention is defined by the claims and may include other examples that a person skilled in the art may conceive. Such other examples are intended to be within the claims if they include structural elements that are not different from the language of the claims, or equivalent structural elements that do not substantially differ from the language of the claims.

[0102] Further aspects of the present invention are provided by the subject matter of the following clauses: a method for controlling access to restricted functions of a computing device, comprising: one or more electronic processors receiving a request from a user for access to restricted functions of the computing device, wherein the access request identifies at least a portion of the restricted functions of the computing device to be unlocked for access by the user; one or more electronic processors transmitting the request to a trusted license store; one or more electronic processors receiving license-indicating data from the trusted license store, wherein the license-indicating data includes an identifier for a portion of the restricted functions to be unlocked for access and a number of times the user may access the restricted functions; one or more electronic processors determining that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions; and, in response to the determination that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions, one or more electronic processors providing the user with access to the restricted functions.

[0103] A method of one or more of these provisions, further comprising the step of sending a request to a trusted license store including establishing a secure mutual authentication network connection to the trusted license store, and the step of receiving license-indicating data including receiving license-indicating data from the trusted license store via the mutual authentication network connection.

[0104] A request that includes credentials associated with the user, in any way that falls under one or more of these clauses.

[0105] A method of one or more of these clauses, in which the data indicating the license further includes identification information for the binary file to be executed, and the step of providing access to restricted functionality enables the execution of the binary file on a computing device.

[0106] A method of one or more of these clauses, further comprising the step of executing a binary file by one or more electronic processors, wherein the binary file runs a software image version on a computing device.

[0107] A method of one or more of these clauses, wherein the step of executing a binary file on a computing device includes enabling the execution of a single software application by one or more electronic processors, which permits a limited set of operations for the computing device.

[0108] A method of one or more of these provisions, which includes a step of executing a binary file on a computing device, which includes enabling one or more electronic processors to access a shell having a limited set of tools and actions, and the access to the shell is restricted by one or more access controls.

[0109] A method of one or more of these clauses, wherein the step of determining whether a user has accessed a restricted feature more times than the number of times the user is entitled to access the restricted feature includes comparing the number of times the user is entitled to access the restricted feature with a monotonic counter on a computing device.

[0110] A method by which one or more of these clauses are used to determine that a user has not accessed a restricted feature beyond the number of times they are allowed to access it, if the value of a monotonic counter is less than or equal to the number of times the user is allowed to access the restricted feature.

[0111] A method of one or more of these clauses, further comprising the step of incrementing a monotonic counter by one or more processors in response to the execution of a binary file.

[0112] A method of one or more of these clauses, further comprising the step of verifying a binary file by one or more processors before enabling execution of the binary file.

[0113] A method according to one or more of these clauses, wherein the step of verifying a binary file includes: determining a public key associated with the binary file by one or more processors; determining a public key hash value based on the public key by one or more processors; comparing the public key hash value with a programmed hash value accessed from a first set of fuses of a computing device by one or more processors; verifying the signature associated with the binary file using the public key in response that the public key hash value is equal to the programmed hash value; and enabling the execution of the binary file in response that the verified signature matches a calculated hash value of the binary file.

[0114] A method according to one or more of these provisions, further comprising the step of using one or more processors to identify a first set of fuses, including programmed hash values, based on the values ​​of the switch fuses of a computing device.

[0115] A method according to one or more of these provisions, wherein the step of verifying a binary file includes: determining a security version number associated with the binary file by one or more processors; comparing the security version number with a programmed value associated with a first set of fuses of a computing device by one or more processors; and enabling the execution of the binary file in response that the security version number value is greater than or equal to the programmed value.

[0116] A method of one or more of these clauses, further comprising the step of identifying a programmed value based on the value of a switch fuse in a computing device using one or more processors.

[0117] A method of one or more of these clauses, further comprising the step of irrevocably changing the value of a switch fuse by one or more processors in response to user input indicating that a programmed hash value has been compromised.

[0118] A method of one or more of these clauses, further including the step of not executing the binary file in response to the binary file not being validated.

[0119] A method of one or more of these clauses, further including the step of rebooting the computing device in response to the binary file not being validated.

[0120] A computing device comprising: one or more processors; a non-temporary computer-readable medium containing instructions that, when executed by the one or more processors, cause one or more processors to perform an operation, wherein the operation includes the steps of: receiving a request from a user for access to restricted functions of the computing device, wherein the access request identifies at least a portion of the restricted functions of the computing device to be unlocked for user access; sending the request to a trusted license store; receiving license-indicating data from the trusted license store, wherein the license-indicating data includes identifiers of the portion of the restricted functions to be unlocked for access and the number of times the user may access the restricted functions; determining that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions; and, in response to determining that the user has not accessed the restricted functions more times than the number of times the user may access the restricted functions, providing the user with access to the restricted functions.

[0121] Non-temporary computer-readable medium, which, when executed by one or more processors, includes instructions causing one or more processors to perform an operation, the operation comprising: receiving a request from a user for access to restricted functions of a computing device, wherein the access request identifies at least a portion of the restricted functions of the computing device to be unlocked for user access; sending the request to a trusted license store; receiving license-indicating data from the trusted license store, wherein the license-indicating data includes identifiers of the portion of the restricted functions to be unlocked for access and the number of times the user may access the restricted functions; determining that the user has not accessed the restricted functions more times than the number of times the user may access them; and, in response to determining that the user has not accessed the restricted functions more times than the number of times the user may access them, providing the user with access to the restricted functions. [Explanation of symbols]

[0122] 100 Computing Devices 105 Processors 110 Input-Output Interfaces 115 Human-Machine Interface 120 memory 121 Command 122 data 125 Limited Features 130 Software Images 135 Monotonic Counter 140 Trust Stores, Trusted License Stores 145 Mutual Authentication Network Connector 150 Two-factor authentication systems 155 Secured Boot Function, Secure Boot Function 160 First set of fuses 165 Second set of fuses 170 Switch Fuse 175 Smart Card Reader 180 Credentials 200 Trusted License Servers 205 Second Mutual Authentication Network Connector 210 License Store 250 Secured Communications Networks 300 Two-Factor Authentication Servers 305 Request Handler 310 Code Generator 315 Code Authentication Department 320 User Data Store 350 Secure Communication Network 375 Authentication Devices 380 Authentication Applications 400 processes, methods 402 blocks 404 Block 406 blocks 408 blocks 410 blocks 450 processes 452 blocks 454 blocks 456 blocks 462 blocks 464 blocks 466 blocks 468 blocks 500 ways 502 blocks 504 blocks 506 blocks 508 blocks 510 blocks

Claims

1. A method (500) for controlling access to restricted functions (125) of a computing device (100), Step (502) of receiving a request from a user for access to restricted functions (125) of a computing device (100) by one or more electronic processors, wherein the access request identifies at least a portion of the restricted functions (125) of the computing device (100) to be unlocked for access by the user; The steps include: sending the request to the trusted license store (140) using one or more electronic processors (504); Step (506) of receiving license-indicating data from the trusted license store (140) by one or more electronic processors, wherein the license-indicating data includes an identifier of a portion of the restricted function (125) to be unlocked for access, and the number of times the user may access the restricted function (125). The step (508) of determining by one or more electronic processors that the user has not accessed the restricted function (125) more times than the number of times the user is allowed to access the restricted function (125), In response to determining that the user has not accessed the restricted function (125) more times than the number of times the user is entitled to access the restricted function (125), one or more electronic processors provide the user with access to the restricted function (125). Method (500), including the method (500).

2. Step (504) of sending the request to the trusted license store (140) includes establishing a secure mutual authentication network connection to the trusted license store (140), The step (506) of receiving the data indicating the license includes receiving the data indicating the license from the trusted license store (140) via the mutual authentication network connection. The method according to claim 1 (500).

3. The method according to claim 1 (500), wherein the request includes credentials (180) associated with the user.

4. The method according to claim 1 (500), wherein the data indicating the license further includes identification information for a binary file for execution, and the step of providing access to the restricted functionality (125) includes enabling the execution of the binary file on the computing device (100).

5. The method of claim 4 (500), further comprising the step (510) of executing the binary file by one or more electronic processors, wherein the binary file executes a software image version on the computing device (100).

6. The step (510) of executing the binary file on the computing device (100) is, The one or more electronic processors enable the execution of a single software application that permits a limited set of operations for the computing device (100), The one or more electronic processors enable access to a shell having a limited set of tools and actions, wherein access to the shell is limited by one or more access controls. The method according to claim 5 (500), comprising at least one of the following.

7. The step (508) of determining whether the user has accessed the restricted function (125) more times than the number of times the user is allowed to access the restricted function (125) includes comparing the number of times the user is allowed to access the restricted function (125) with a monotonic counter (135) of the computing device (100), If the value of the monotonic counter (135) is less than or equal to the number of times the user can access the restricted function (125), it can be determined that the user has not accessed the restricted function (125) more than the number of times. The method according to claim 1 (500).

8. In response to the execution of the binary file, one or more processors increment the monotonic counter (135). The method according to claim 7 (500), further comprising:

9. Before enabling execution of the binary file, one or more processors verify the binary file. The method according to any one of claims 4 to 8, further comprising (500).

10. The step of verifying the aforementioned binary file is: The steps include determining the public key associated with the binary file using one or more processors, The steps include: determining a public key hash value based on the public key using one or more processors; The steps include: comparing the public key hash value with a programmed hash value accessed from a first set of fuses (160) of the computing device (100) by one or more processors; The steps include: verifying the signature associated with the binary file using the public key in response that the public key hash value is equal to the programmed hash value; The steps include enabling the execution of the binary file in response to the verified signature matching the calculated hash value of the binary file, and Includes, The above method (500) is preferably, The step of using one or more processors to identify the first set of fuses (160) including the programmed hash value based on the value of the switch fuse (170) of the computing device (100) Further including, The method according to claim 9 (500).

11. The step of verifying the aforementioned binary file is: The steps include determining the security version number associated with the binary file using one or more processors, The steps include comparing the security version number with a programmed value associated with a first set of fuses (160) of the computing device (100) using one or more processors, The steps include enabling the execution of the binary file in response to the security version number value being greater than or equal to the programmed value, and Includes, The above method (500) is preferably, The step of identifying the programmed value based on the value of the switch fuse (170) of the computing device (100) using one or more processors. Further including, The method according to claim 9 (500).

12. In response to user input indicating that the programmed hash value has been compromised, The step of irreversibly changing the value of the switch fuse (170) using one or more processors. The method according to claim 11, further comprising (500).

13. In response to the fact that the aforementioned binary file was not verified, The step of not executing the aforementioned binary file, and / or Step of rebooting the computing device The method according to claim 9 (500), further comprising:

14. One or more processors (105), A non-temporary computer-readable medium including an instruction (121) that causes the one or more processors (105) to perform an operation (500) according to any one of claims 1 to 13 when executed by the one or more processors (105), and A computing device (100) equipped with the following.

15. A non-temporary computer-readable medium comprising, when executed by one or more processors (105), instructions (121) causing the one or more processors (105) to perform an operation (500) according to any one of claims 1 to 13.

Images