Abstract: A terminal device seeking access to a mobile network retrieves a handset identifier identifying the terminal device and a cryptographic key for proving an identity of the terminal device from storage circuitry of the terminal device. The terminal device generates signature information by signing a block of information including the handset identifier using the cryptographic key. During a network connection process for negotiating access to the mobile network with a network control device, the terminal device communicates the signature information to the network control device.

Abstract: Device verification extension technology obtains, in response to a request to verify a signature associated with first data, an asymmetric verifier application from off-device storage. The asymmetric verifier application is loaded and executed. The signature associated with the first data is verified using the asymmetric verifier application using asymmetric-key cryptography.

Abstract: An authentication method is disclosed, the method comprising: receiving at least one request for an action in relation to an electronic device, wherein performance of the action requires verification of an association of a group of IDs specified by the request; verifying, via cryptographic verification, whether the group of IDs specified by the request match a cryptographically attested group of IDs associated with the electronic device, to determine whether the at least one request for an action is an authentic request; and, having determined the at least one request for an action is an authentic request, approving the at least one request, wherein the group of IDs comprises at least an Integrated Circuit Card Identifier (ICC ID) of a Subscriber Identity Module (SIM) of the electronic device and a device identifier associated with the electronic device.

Abstract: A trusted execution environment migration method for a device comprising a multicore processor, the processor operable to execute a rich execution environment (REE) and a trusted execution environment (TEE), the method comprising: executing a TEE scheduler in the REE on a first core of the multicore processor; subsequent to a migration of the TEE scheduler from the first core to a second core, issuing a request, by the TEE scheduler and to a transition submodule in the TEE, to execute an operations submodule in the TEE, wherein the transition submodule is operable to manage the transition of a core of the processor between execution of the REE and execution of the operations submodule in the TEE, and wherein the transition submodule is executed on the same core as the TEE scheduler; upon execution of the operations submodule, determining if the core on which the operations submodule is executing has changed since the previous execution of the operations submodule.

Abstract: A trusted execution environment scheduling method for a device comprising a multicore processor, the processor operable to execute a rich execution environment (REE) and a trusted execution environment (TEE), the method comprising: providing a REE global scheduler in the REE, the REE global scheduler operable to schedule threads for execution in the REE; providing a TEE scheduler in the TEE, the TEE scheduler operable to schedule threads for execution in the TEE, wherein the TEE scheduler determines a number of runnable TEE threads which are either presently, or are awaiting, execution in the TEE and stores the number of runnable TEE threads in a location accessible to threads executing in the REE; providing a plurality of worker threads in the REE, the worker threads being in an activated state or in an deactivated state, wherein when an activated worker thread of the plurality of worker threads is executed according to the schedule of the REE global scheduler the worker thread makes a call to the TEE to cau

Abstract: A software installation method is provided for a device comprising non-volatile memory 10 and access control circuitry 6 to control access to the non-volatile memory based on region defining data 7 defining whether a given region of the non-volatile memory is a less secure region or a more secure region, with greater access restriction imposed on access to a more secure region than to a less secure region. The method comprises installing target software 40 in a target region of the non-volatile memory 10 defined by the region defining data as a less secure region; verifying the target software; and at least when verification of the target software is successful, and after installation of the target software, updating the region defining data 7 to change the target region from a less secure region to a more secure region.

Abstract: A method for a device comprises enrolling a specified application installed on the device into a chain of trust provided by a private key infrastructure. In the chain of trust, a child certificate is attested as valid by an attestor associated with a parent certificate in the chain of trust. Enrolling includes generating an application certificate 20-A for verifying that the specified application is installed on the device 2. The application certificate is a descendant certificate of the device certificate associated with the device and the chain of trust.

Abstract: An anonymous attestation cryptographic protocol is provided for enabling a target (device 4) to attest to a predetermined property of the device without needing to reveal its identity to a verifier (8). When obtaining a credential from an issuer (6) to attest to the predetermined property, the credential is validated by an intermediary device (2) which is a separate consumer electronics device to the target device (4) itself. This allows the relatively processor-intensive calculations required for validating the credential to be performed on a separate device (2) from the device (4) for which the attestation has been made, allowing anonymous attestation protocols to be used for lower powered target devices such as sensors in the internet of things.

Abstract: A method for providing an attestation for enabling a device to attest to an assertion concerning the device, comprising: generating an attestation identifier and a base-secret code corresponding to the attestation identifier; providing the attestation identifier and a validation-secret code to a validation apparatus for storage in conjunction with the assertion, wherein the validation-secret code is based on the base-secret code; providing the attestation identifier and a device-secret code to a manufacturer or adapter for provision to a device, wherein the device-secret code is based on the base-secret code.

Abstract: A network usage control method comprises receiving (S2, S5) a handset identifier (e.g. an IMEI number) of a requesting terminal device (2) seeking to use a mobile network (4); retrieving verification information (S7) for verifying an identity of an authorised terminal device associated with the handset identifier; verifying (S9), based on the verification information, whether the requesting terminal device (2) is the authorised terminal device; and controlling (S10, S11) usage of the mobile network by the requesting terminal ON device in dependence on whether the requesting terminal device is verified as the authorised terminal device. Cryptographic keys can be used to bind the handset identifier to a particular handset and verify that a device presenting a given handset identifier is actually the authorised handset for that handset identifier. This prevents thieves being able to circumvent blacklisted handset identifier of a stolen handset by cloning a valid handset identifier from another device.

Abstract: A software decryption key is injected into a computing device 2 having a secure execution environment 20 and a less secure execution environment 22. The key 38 is for decryption of software to be run on the computing device. A key injection software component 36 executed within the secure execution environment 20 is used to control storage of the software decryption key 38 in a protected state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment 22 of the computing device. Software provided to the device is decrypted based on the injected software decryption key 38.

Abstract: To establish a first protected communication channel between a device D and a first server S, a symmetric key KS is derived at the device D, based on a device identifying key KD and public key information dependent on a first server public key Spublic of the first server S. The symmetric key KS is derived in a corresponding way at a second server T. The symmetric key KS is transmitted from the second server T to the first server S on a second protected communication channel. Communication on the first protected communication channel between the device D and the first server S is protected using a communication key KC which is dependent on the symmetric key KS. This can enable a device D lacking support for asymmetric key cryptography to securely enter into communication with the first server S.

Abstract: A method for performing secure change of operational mode of a multi-SIM telecommunications device, the method comprising: enabling each of a plurality of modem modules of the telecommunications device in a limited operational mode; performing a first verification, by a first authentication module of a plurality of authentication modules of the telecommunications device, to verify the validity of a first subscriber identity module associated with a first modem module of the plurality of modem modules in accordance with network configuration information, wherein responsive to a positive first verification the first modem module is transitioned to an enhanced operational mode and the first modem module performs a network attachment procedure to a first network using the first subscriber identity module; performing a second verification to verify active attachment of the first modem module to the first network in accordance with the network configuration information; providing the result of the second verificati

Abstract: A method for post-manufacture certificate generation for an electronic device 4 comprises obtaining a public key from the electronic device 4, and enrolling the device in to a chain of trust provided by a public key infrastructure in which a child certificate is attested as valid by an attestor associated with a parent certificate in the chain. The enrolling comprises generating an electronic device certificate 30-I for the chain of trust using the public key 32 obtained from the electronic device. The enrolling is performed at an enrolment device 6 separate from the electronic device 4. The electronic device certificate 30-I is a descendant certificate of the enrolment device certificate 30-D associated with the enrolment device 6.

Abstract: A method of post-manufacture generation of the device certificate 20 for verifying an electronic device 2 according to a public key infrastructure is provided. The method comprises obtaining, at a certificate generating apparatus 40, a first key 42 associated with the device 2. A second key 22 for the electronic device is derived from the first key 42. The device certificate 20 for the PKI is generated with the second key acting as the public key 22 associated with the device certificate 20. In a corresponding way a private key 24 for the PKI can be generated by the electronic device 2 based on a shared first key 42. This approach enables the manufacturing cost for manufacturing an electronic device to be reduced whilst still enabling use of a PKI for attesting to properties of the device 2.

Abstract: A method for verifying whether an electronic device is one of a group of known devices comprises receiving verification information indicative of a first device identifier accessible from storage circuitry by a predetermined process executed by the electronic device and a second device identifier inaccessible from the storage circuitry by the predetermined process. A device database retains valid pairings of the first and second device identifiers for the group of known devices. The device database is looked up based on the verification information to determine whether the first and second device identifiers correspond to one of the valid parings.

Abstract: A method is provided for installing or updating software on an electronic device 2 comprising processing circuitry 4 and memory access circuitry 10 to control access to at least one memory unit 6, 8 in response to physically-addressed memory access requests issued by the processing circuitry specifying physical addresses from a physical address space. The method comprises performing an address layout varying process comprising: obtaining at least one seed value; in dependence on the at least one seed value, selecting one of a plurality of software address layouts for code or data associated with the software, each software address layout corresponding to a different layout of the code or data in the physical address space; and triggering the electronic device to write the code or data associated with the software to locations of said at least one memory unit corresponding to the selected software address layout.

Abstract: A method for validating an electronic device 2 includes receiving attestation information provided by the electronic device 2 attesting that the electronic device 2 has received a plurality of event attestations. Each event attestation provides a cryptographically authenticated attestation to the occurrence of a respective event during a lifecycle of the electronic device. A validation result is determined that indicates whether the attestation information is valid. Providing separate cryptographically authenticated attestations for respective events in the lifecycle of the device can simplify manufacturing of the devices in a multistage manufacture process compared to an approach using a single device-specific attestation attesting that the entire process is trusted.

Abstract: A method of configuring a target domain providing a cryptographic identity for authenticating commands to be executed by an electronic device comprises receiving a domain configuration command, and authenticating the command based on a cryptographic identity provided by an authenticating domain which is an ancestor of the target domain in a hierarchical chain of trust. When authenticated, at least one target domain constraint specified by the command is combined with at least one future constraint specified by the authenticating domain to generate a combined constraint set to be satisfied by commands to be authenticated by the target domain. The combined constraint set is stored for the target domain. This approach provides a balance between security and scalability of the chain of trust.

Abstract: A device has an installed cryptographic program that performs cryptographic operations in dependence upon a received diversification value. The diversification value is generated by an obfuscated personalisation program installed in the device and is dependent upon a personalisation input to the personalisation program. The personalisation input is characteristic of the particular execution environment provided by the device, and may take the form of a proper subset selected from among variables characterising the device, such as hardware properties, static software configuration and results from processing dynamic variables to check that they have expected properties. The diversification value generated by the personalisation program is returned (in encrypted form) to a server which also has a copy of the cryptographic program. Thus, the server and the device may communicate using a secure channel provided by the combination of the cryptographic program and the diversification value.