BACKGROUND

[0001] Device management can include the use of authorisation certificates which may have been signed using administrator keys to allow a user of the device to access particular software. Security settings or platform level features may be changed by an administrator using a password.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various features of certain examples will be apparent from tire detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example only, a number of features, wherein:

[0003] Figure 1 is a schematic of a registration protocol according to an

[0004] Figure 2 is a Schematic of a reboot validation protocol according to an example;

[0005] Figure 3 is a schematic of a normal usage protocol according to an example; and

[0006] Figure 4 is a computer-readable medium comprising instructions for carrying <xit a security prptocdl according to an example.

DETAILED DESCRIPTION

[0007] In the following description, for purposes of explanation, numerous specific details of certain examples are set forth. Reference in the specification to "an example* or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least that one example, but not necessarily in other examples.

[0008] Within a system there are platform level features that can be managed either from a remote management system or from a local console. Such features may include firmware setting including security features, such as unified extensible firmware interface (UEFI) or basic input/output system (BIOS), additional hardware devices linked to the system, and functions running outside of the operating system (OS), such as on an additional processor or within a virtualization layer for example.

[0009] Management systems to manage a UEFI/BIOS or hardware functionality can be invoked at boot-time using an administrator password for example. Management can also be performed remotely using an agent feat can call an instrumentation interface through to the UEFI/BIOS for example.

[0010] A management command can be provided in order to affect changes in configuration settings of a local device, such as firmware settings for example. In a remotely managed device, changes to configuration settings of toe device can be signed with a private key controlled by a management application. According to an example, the management application can securely manage toe private key used for the signature process from a remote (to toe device) location.

[0011] According to an example, when management commands are signed by a private key associated with a management application (local or remote), toe device being managed can trust the signed command. For example, the device being managed can trust that its public key is associated with toe private key being used to sign toe command. There may be a process that is provided for registering the public key at toe device which then acts as toe management authority. For example, toe public key may be registered with a firmware component of the device or other component that controls configuration settings or other security settings erf toe device. (0012} According to an example of a remotely managed case, a certificate can be issued by a trusted authority (such as a certificate authority) to toe domain of the enterprise using a name that a user will recognise, in a locally managed example,“self-signed certificates" can be used in which a user or administrator is relied upon to validate the management steps for controlling toe device or effecting changes to toe device security settings.

[0013} According to an example, a security processor or secure crypto- processor in a local device, such as a laptop for example, can form a secure execution environment. The execution environment may be segregated from an operating system or management application of toe device. According to an example, the security processor can create a private/public key pair which can be registered with a component of the local device, such as the firmware for example.

[0014] According to an example, a device accepting a public key can trust that an associated private key has been created and/or managed within a security processor that is local to the device, i.e. that is on toe same platform. This provides trust in the local management of toe device.

[0015] According to an example, a security processor can use a private key that it has created to sign a management command. For example, a management command may be a command to alter a device configuration setting. The signed command can be sent to a component of toe device with which toe private/public key pair has been registered.

[0016] To register toe key for use as a management key toe first stage is to generate a public private key pair within a security processor along with creation information. Them toe private key is used to create a self-signed certificate also containing toe creation information. This certificate is passed through to firmware (e.g. UEFI or BIOS) to register it as a management key. The next time that the device (e.g. laptop) boots or comes out of a hibernation state the certificate is verified. This includes verifying the creation information to check that the key is created and managed within toe security processor. Once this verification has happened the public key within the certificate is registered as the authorised management key, i.e. a term of use. If the verification fails no management keys are registered.

[0017] According to an example, device platform features, such as firmware and hardware functionality, can be managed according to terms of use using a private/public key pair that can be created and controlled by a security processor on the device. An example of a security processor may be a Trusted Platform Module (TPM) of the device or a secure crypto-processor. The TPM may be a microchip on the motherboard on the device which can communicate with components of tee device via a hardware bus. The private/public key pair may be referred to as management keys. The keys can be validated, as being created in and managed by the TPM, locally for secure management and control of platform features. tO018] According to an example, management keys a re generated using a TPM of the device. The management keys that the TPM cam generate can relate to a crypto-graphic privateZpublic key pair. The private/public key pair is generated in such a way that the private key can be unencrypted within the TPM. Platform features can be controlled and managed at the local device level based the management public key registered with tee platform.

[0019] According to an example, tee configuration of firmware options and/or lower level components or settings can be delivered via an operating system of the device via the firmware component. The device can be locally or self- managed based on signed commands being generated by the user on tee local device from within a management application running on the operating system. The signed commands can be pushed down to the one or more components, such as via the device firmware for example.

[0020] According to an example, a threat is an action or process that may lead to a downgrading of security on a device. For example, a threat may occur when the device is infected with malware that has tee ability to sign management commands to a component such as the device firmware. In an example, crypto-graphic keys are managed within a TPM using pin-based authorization from a user to mitigate such threats. This security policy can be enforced by the component or firmware in question (to which the signed command relates) accepting only a TPM managed public key (this may represent a term of use). For example, where there is local management or if remote management a properly issued X509 certificate may be provided.

[0021] In an example, management keys can be created in a device security processor or TPM and registered with a component, firmware or other system component, such as an additional security processor for example, This provides a method of securely managing platform level features on a local client device secured by keys protected and managed within the security processor or TPM of the device.

[0022] Figures 1 and 2 are schematic representations of process flows or protocols for authenticating a signer according to an example. Referring to Figure 1, a private/public key pair is generated 101 locally within a security processor or TPM 102 of a device 100 such as a laptop, When the private/public key pair 101 is generated or created, associated creation ticket information 105 can be stored on the OS so teat they can be recognised as correct by the security processor or TPM 102. For example, the TPM can be used during the boot process and/or from tee OS. In an example, the creation ticket information is returned to the creator of the key. The ticket is secured so that tee TPM can validate that it created the ticket and that it relates to the key. For example, tee creation ticket information is signed using an HMAC that only the TPM knows about.

[0023] According to art example of a locally managed certification process, tee security processor 102 on the local device 100 may:

- during a registration protocol (A), generate a private/public key pair 101 within the security processor (TPM) 102 and save associated TPM creation ticket information 105;

- generate a seif-signed certificate 113, where the certificate structure is sighed by the private key it is certifying. For example, the TPM ticket creation information can be contained within the certificate as fields within the name field or otherwise supplied separately; - send or register 115 the self-signed certificate and the TPM creation ticket information at die component 103, 109 as a registration command.

[0024] The validated public key is registered 215 with one or more components 109 of the local client device 100, such as the device firmware for example 103. This means that commands signed using this key will be accepted.

[0025] According to an example, when the private/public key pair 101 is created by the TPM 102, associated structures are formed and returned from either a “Create" or“CreatePrimary'* operation:

-“CreationData" structure which defines the terms under which the key was created. This may include any requested PCR measurements, and foe name of foe parent of the key or terms of use.

-“CreationHash” is the hash of the creation data structure.

-“CreationTicket* is a HMAC value formed from the“KeyName” (derived from the public key and any associated polities to control key usage) along with the "CreationHash*. The HMAC is formed using an internal TPM proof key so that only the TPM can create and validate the ticket.

[0026] When the management system creates a key pair, the key pair (and associated structures) is stored or retained within the management system. The "CreationData" structure is encoded into the“CreationHash” and so, if only the existence of the key in the TPM is being checked rather titan the creation conditions, then It is not necessary to deal with this structure.

[0027] According to an example, when the self-signed certificate 113 is created it can include a subject name that may be made up of a number of fields such as a common name (CN), organization (o) and/or multiple Organizational Unit names (OU). These creation structures can be placed in the OU fields as base64 encoded strings with appropriate identifiers. As such, the application programming interfaces (APIs) can be the same between a remotely and locally managed certification process, since all registration information is shipped in foe certificate. (0028} Figure 2 is a schematic representation of a process flow tor validating a certify creation command according to an example. Following registration 115 of tiie self-signed certificate and public key with the component 109, at the next boot time of tiie device 100 the component 109 generates a certify creation command 207. The certify creation command 207 is used to verify that the private/public key pair was generated in the local security processor 102, i.e. to confirm whether or not the certify creation command can be trusted. Accordingly, there can be a confirmation, in tiie trusted execution state, of suitability of use of the public key part of the key pair for authorising management commands.

[0029] According to an example, tiie certify creation command is generated by creating a restricted signing key 201 within the local TPM 102. In an example, the component 103 can decode 203 the public key from tiie self-signed certificate 113. The public key 101b can be decoded into a form that is loadable into the security processor or TPM 102. The security processor can then create or generate the restricted signing key 201. The public key 101b and creation ticket information 105 can both be loaded 205 into tiie local TPM 102. The restricted signing key 201 can be used to sign 209 both the loaded public key 101b and the creation ticket information 105. If a resulting structure is created and correctly signed from executing the certify creation instruction then the self- signed certificate and public key are trusted to have been generated in the local security processor or TPM 102 and the CreationData can also be checked to see any policies are applied to the management key. If tiie signed certify creation structure is verified then the self-signed certificate and public key are trusted.

[0030] According to an example, provided that tiie self-signed certificate and public key are trusted by the firmware component 103, tiie public key is registered with a configuration component 109 that can then allow a management command to effect changes to security settings of tiie device 100.

[0031] According to an example of a locally managed certification process, tiie component 103, 109 on the local device 100 may: - at the next boot time (B), look 203 at the registration command 115 and associated certificate and recognize it as a self-signed certificate 113;

- create a restricted-signing key 201 within the platform hierarchy of the TPM (or identify one already created 200);

- use 205 the public key 101b in the self-signed certificate 113 along with tee TPM creation ticket information 105 to form a TPM certify creation command

207;

- instruct tee TPM 102 to run tee certify creation command 207 using the restricted signing key 201 to sign the resulting structure 209;

- if the TPM 102 generates tee signed structure 209 then the public key 101b is one associated with a TPM created key 101 and as such tee private key 101a is managed within the security policy;

- if the resulting structure 209 is created then the component 103, 109 (e.g. the UEFI or BIOS) can toil the user 221 that the device system is being registered to be managed locally and/or may display any additional name information in the self-signed certificate 113;

- if the TPM 102 does not generate or create a signed structure then an error or an appropriate error message can be given or displayed to the user.

- provided that the TPM generates the signed structure and tee public key is confirmed to be associated with the TPM created key, tee public key is registered with tee component in question.

[0032] According to an example, the validation process or protocol (B) can include the following steps:

- recognize tee certificate 113 is seff-signed.

- decode 203 the subject name fields and look for information relating to the “CreationTicket” and“CreationHash” and if present the“CreationData” structure.

- recreate tee “CreationTicket” and “CreationHash” (and “CreationData”) as binary blobs for TPM loadable commands.

- if tee“CreationData" is present check the“Creation Data” meets any policies specified and hash it to tee“CreationHash".

- if tee information is present teen: a. decode 203 the public key 101b from foe certificate 113 in a form loadable into the TPM 102. b. use "CreatePrimary" to create a restricted signing key 201 within foe platform hierarchy. c. use foe“LoadExtemal” TPM command to load foe public key into foe TPM and obtain a handle to the key. d. use tire“CertifyCreation” TPM command to validate 211 the resulting ticket or structure (and "CreationHash”). If foe resulting structure is correct this will lead to the signing of a "TPM2B_ATTEST” structure, otherwise an error is returned.

- check that a signature is produced.

- if the checks at any stage fail, then foe provisioning can be rejected with appropriate messages 221 to the user 104 and logs may be written. The checks may foil if: a. foe self-signed certificate 113 does not contain creation ticket information

105, b. the creation ticket information 105 does not parse property, or

C. foe generation of the“CertifyCreation" signature foils and ah error is returned.

- If the checks succeed, then the user 104 can be asked to confirm that the management key 101b be installed and data representing foe confirmation can be generated.

[0033] According to an example, for a remotely managed certification process the private/public key pair may be generated at a management server, or an associated hardware security module (HSM). The local device or enterprise may obtain a Certificate (signed by a certificate authority) for foe key pair that is associated with their domain. Registration to foe local client device may occur with a register command and the certificate may be submitted to a component 103, 109 of foe local device, e.g. UEFI or BIOS, On the next boot, the component 109 or UEFI/B!OS 103 can check foe self-signed certificate and may display the domain name as an identifier to the user who can accept the registration.

[0034] Referring to the example of Figure 3, a management command 301 can be used to effect one or more changes in the features or firmware settings of the device platform. In an example, the management command 301 can be created using the public key 101b (from the key pair 101 that was generated in the device security processor 102) and the creation ticket information 105. The device TPM 102 can use 305 the private key 101a from the private/public key pair to sign 307 file management command 301 locally. Hie command 301 may be signed using a pin-based authorisation 309 and by access to a master storage root key stored in the TPM 102. For example, a user 104 of the device can be prompted to enter a PIN number 109. When the management command is signed, a signed command 311 is generated. The signed management command is sent to the configuration component 109 or firmware component 103 (e.g. UEFI/BIOS). According to an example, the component 109 can perform a step of validating 315 teat the public key is the registered key in step 215 and hence managed by the security processor or TPM. The signed command can be validated using the public key 101b registered with the configuration or firmware component in question 315. If toe command is trusted the requested changes to the configuration settings according to toe command are made 317. If the command is not trusted there are no changes made to toe configuration settings of the device. As such the component 109 is able to trust tiie signing key 101b by authenticating toe signer. Provided that the management command 301 can be trusted, the component 109 then enforces changes to the configuration of the firmware settings according to the management command 301.

[0035] According to an example, for a locally managed certification process each user does not have to go to the expense and challenge of obtaining a domain and associated certificate (as compared with the remotely managed certification process).

[0036] According to an example: 1 ) A Management App creates a management key and tries to register: a. Management App creates keys in TPM (protected with a user pin) - management app keeps creation information (creation ticket/creation hash) b. Management App uses foe TPM to create a self-signed certificate (x509 cert) c. The management App then tiles to register the self-signed certificate as the management authority through the UEFI/BIOS which will distribute to the appropriate process (this call to register foe keys can include a creation ticket/creation hash).

2) On a reboot and prior to booting the OS the UEFi/BIOS validates foe management keys: a. The UEFI/BiOS checks certificate i. if it is self-signed it does these checks else if checks certificate is a valid EVCert and shows name to user (but not covering this here) it. Extracts public key from the certificate (managementPubiicKey b. The UEFI/BIOS looks at key creation information with the registration command (could be coded in the seifs igned cert) c. The UEFt/BiOS checks the creation information i. It creates a restricted signing key in the platform hierarchy ii. Using this key it gets foe TPM to sign a“CertifyCreation’* command hence passes foe public key, creation information and foe restricted signing key it has just created ill. The UEF!/BiOS checks the Signed certify creation structure from foe TPM to confirm that the managementPubiicKey is a TPM managed key (if this fails registration fails) d. The UEFI/BIOS (still prior to booting the OS) checks with the user that they are expecting a local app to take control of the management e. If the user says yes the UEFI/BIOS sends the managementPublicKey to the component that will be managed f. Registration Is now complete

3) Normal Usage - When the user wants to change a setting oh the component: a. Form an appropriate command structure using a GUI on the Management App b. The user enters the pin for the keys c. The user loads the private key into the TPM and the pin as an authorization value (the TPMs may not store private keys but they can be stored on the OS in encrypted form such that the TPM can decrypt foe private keys). d. The TPM Is used to sign the command. e. The command is sent to the component being managed f. The component uses the registered managementPub! icKey to check the signing and If correct performs the changes, i.e. the component checks that the public key meets the terms of use under which the public key can be used.

[0037] Figure 4 shows a schematic representation of a computer-readable medium comprising instructions for carrying out a protocol according to an example.

[0038] The methods described herein protect configuration settings from being updated by malware should the local device be compromised, since the keys are generated and controlled by the security processor which is separate from the operating system. The security of managing the platform level features is increased by the signing of the management commands. This uses a validation process whereby the signing keys are either trusted or not trusted. The cryptographic keys are well managed by the TPM or security processor on the local client device. One of the components of foe local device performs a validation of foe management keys to check that the keys are created and controlled from within foe TPM. This reduces foe chance that the keys will be subverted or foe platform security features weakened If malware gets hold of the management keys. This allows the user to ensure that platform level features are securely managed when foe device is locally managed, l.e. it ensures that the keys are managed through foe TPM and hence resilient from software attacks if foe device is compromised.

[0039] While foe method, apparatus and related aspects have been described with reference to certain examples, various modifications, changes, omissions, and substitutions can be made without departing from foe spirit of the present disclosure. In particular, a feature or block from one example may be combined with or substituted by a feature/block of another example.

[0040] The word "comprising* does not exclude the presence of elements other than those listed in a claim, "a* or "an* does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in foe claims.

[0041] The features of any dependent claim may be combined with foe features of any of foe independent claims or other dependent claims.