WO2021253040A1

WO2021253040A1 - Machine to machine communications

Info

Publication number: WO2021253040A1
Application number: PCT/US2021/070675
Authority: WO
Inventors: Thomas FOSSATI; Akshitij MALIK; Hannes Tschofenig; Yogesh DESHPANDE
Original assignee: Arm Cloud Technology, Inc.
Priority date: 2020-06-12
Filing date: 2021-06-09
Publication date: 2021-12-16
Also published as: GB2595928A; GB202008953D0

Abstract

Broadly speaking, the present techniques relate to a computer-implemented method of generating an attestation token on an attestor device, the method performed at the attestor device comprising: receiving, from a first requestor, a request for device attestation information; determining, whether the request for device attestation information is an authorised request; when it is determined that the request is an authorised request: generating a first attestation token comprising the attestation information in response to the received request for device attestation information; storing the first attestation token in storage at the attestor device; notifying the first requester that the first attestation token is available to access at the storage; receiving, from the first requestor, an access request to access the first attestation token; providing the first requestor with access to the first attestation token in response to the access request.

Description

MACHINE TO MACHINE COMMUNICATIONS

BACKGROUND

The present techniques generally relate to attestation, for example to attestation of data or devices generating the data.

There are ever increasing numbers of devices within the home, other buildings or the outdoor environment that have processing and communication capabilities which allow them to communicate with other entities (e.g. devices, servers, services etc.) within the same network or on a different network (e.g. on the internet) to access servers or services as part of the "Internet of Things" (IoT)

For example, a temperature device in a home may gather sensed data (e.g. temperature readings) and push the sensed data to a remote service (such as an application running in 'the cloud')· The temperature device may then be controlled remotely by the remote service via received command data.

In other examples, a pollution monitoring device in a factory may comprise a sensor to gather information from various chemical sensors and arrange maintenance based on the gathered information; whilst a healthcare provider may use devices comprising sensors, such as a heart rate monitor to track the health of patients while they are at home.

Entities relying on data from such devices sometimes require some form of attestation, and the present applicant has recognised the need for improved attestation techniques for such communications.

According to a first technique there is provided a computer-implemented method of generating an attestation token on an attestor device, the method performed at the attestor device comprising: receiving, from a first requestor, a request for device attestation information; determining, whether the request for device attestation information is an authorised request; when it is determined that the request is an authorised request: generating a first attestation token comprising the attestation information in response to the received request for device attestation information; storing the first attestation token in storage at the attestor device; notifying the first requester that the first attestation token is available to access at the storage; receiving, from the first requestor, an access request to access the first attestation token; providing the first requestor with access to the first attestation token in response to the access request. According to a further technique there is provided a computer-implemented method of obtaining attestation information from an attestor device, the method performed at a requestor apparatus comprising: transmitting, to the attestor device, a request for attestation information; receiving, from the attestor device a notification that an attestation token comprising the attestation information is available to access at storage on the attestor device; transmitting, to the attestor device, an access request to access the attestation token; accessing the attestation token in response to the access request; providing, to a relying party, the attestation token.

According to a further technique there is provided a computer-implemented method of generating an attestation token on a device having an object hierarchy model, the method performed at the device comprising: establishing a secure communication session with a requestor; receiving, from the requestor, a request for device attestation information, where the request is targeted at an attestation resource of the object hierarchy; determining, whether the request is an authorised request; when it is determined that the request is an authorised request, generating with the attestation resource an attestation token comprising the attestation information in response to the received request; sending the attestation token to the requestor device during the secure communication session.

According to a further technique there is provided a device in accordance with claim 19.

According to a further technique there is provided an apparatus in accordance with claim 23.

According to a further technique there is provided a system in accordance with claim 24.

In a hardware approach, there is provided an electronic apparatus comprising logic elements operable to implement the methods of the present technology. In another approach, the computer-implemented method may be realised in the form of a computer program product, tangibly stored in a non- transitory storage medium, and operable in use to cause a computer system to perform the process of the present technology. BRIEF DESCRIPTION OF THE DRAWINGS

The techniques are diagrammatically illustrated, by way of example, in the accompanying drawings, in which:

Figure 1 shows an example deployment scenario for a device according to the present techniques;

Figure 2a shows an example architecture depicting a client-server relationship between the device of Figure 1 and a server;

Figure 2b shows a schematic diagram of an object hierarchy model on the device of Figure 1; Figure 2c shows a schematic example of a portion of such an object hierarchy model;

Figure 3a shows an illustrative example of a block diagram depicting an attestor device generating an attestation token for a requestor and further depicts the objects, object instances and resources allocated at the attestor device to generate the attestation token;

Figure 3b shows an example communication flow between the attestor device of Figure 3a and a requestor;

Figure 4a shows an illustrative example of a block diagram depicting an attestor device generating attestation tokens for different requestors and further depicts the objects, object instances and resources allocated at the attestor device to generate the attestation token;

Figure 4b shows an example communication flow between the attestor device and requestors of Figure 4a;

Figure 5 shows a flow diagram of an example process of an attestor device generating an attestation token;

Figure 6a shows an illustrative example of a block diagram depicting an attestor device generating an attestation token which is accessed on a substantially synchronous basis; and

Figure 6b depicts an example communication flow between the attestor device of Figure 6a, a requestor and a relying party.

DETAILED DESCRIPTION

Reference is made in the following detailed description to accompanying drawings, which form a part hereof, wherein like numerals may designate like parts throughout that are corresponding and/or analogous. It will be appreciated that the figures have not necessarily been drawn to scale, such as for simplicity and/or clarity of illustration. For example, dimensions of some aspects may be exaggerated relative to others. Further, it is to be understood that other embodiments may be utilized. Furthermore, structural and/or other changes may be made without departing from claimed subject matter. It should also be noted that directions and/or references, for example, such as up, down, top, bottom, and so on, may be used to facilitate discussion of drawings and are not intended to restrict application of claimed subject matter.

Figure 1 shows a deployment scenario 1 according to the present techniques, where a device 2 is operable to communicate with one or more servers or services 4/6. In the present illustrative example servers 4, 6 are depicted as being part of device management platform 8.

Device 2 may be a computer terminal, a laptop, a tablet or mobile-phone, or may, for example, be a lightweight machine to machine (LwM2M) device. Device 2 can be used to provide smart functionality for streetlights, electric meters, temperature sensors, building automation, healthcare, and a range of other market segments as part of the IoT. It will be appreciated that the examples of market segments listed above are for illustrative purposes only and the claims are not limited in this respect.

As described herein each of servers 4/6 may be a single computing device or software running on a computing device. However, the claims are not limited in this respect and one or more of the servers may comprise a plurality of interconnected computing devices (or software running on a plurality of interconnected devices), whereby the plurality of interconnected computing devices may be distributed over one or more public and/or private networks. In the present figures server 4 may, for example, be a LwM2M server which provides deployment of one or more services which may include one or more of: web service(s); data storage service(s); analytics service(s), management service(s) and application service(s), although this list is not exhaustive.

In the present figures server 6 comprises a bootstrap server which is used to provision, for example, data or information at the device 2. In embodiments, bootstrap server 6 may be any type of server or remote machine and may not necessarily be a dedicated bootstrap server. Generally speaking, the bootstrap server 6 is any means suitable to perform a bootstrap process with the device 2 (e.g. machine, hardware, technology, server, software, etc.).

Figure 1 also depicts resource directory 30 at the device management platform 8 which will be described in greater detail below.

In the present examples, the server 4, bootstrap server 6 and resource directory 30 are depicted as being part of a device management platform 8, such as the Pelion™ device management platform from Arm®, Cambridge, UK, although the claims are not limited in this respect.

Further devices/servers/services may require access to the device, where, for example, such devices/servers/services may require to read data stored at or generated by the device 2 or may require to write data or send requests or commands to the device 2. In Figure 1 devices/servers/services are depicted to be application servers 7(1) to 7(n) (where 'h' is an integer), although the claims are not limited in this respect and the devices/servers/services may comprise an edge server, a computer terminal, a laptop, a tablet or mobile-phone, or an application hosted on a computing device and which provides deployment of one or more services.

The device 2 comprises communication circuitry 10 for communicating with the servers 4, 6.

The communication circuitry 10 may use wireless communication such as, for example, one or more of: Wi-Fi; short range communication such as radio frequency communication (RFID); near field communication (NFC); communications used in wireless technologies such as Bluetooth®, Bluetooth Low Energy (BLE); cellular communications such as 3G or 4G; and the communication circuitry 10 may also use wired communication such as a fibre optic or metal cable. The communication circuitry 10 could also use two or more different forms of communication, such as several of the examples given above in combination.

It will be appreciated that the device 2 could also use any suitable protocols for communications including one or more of: IPv6, IPv6 over Low Power Wireless Standard (6L0WPAN®), Constrained Application Protocol (CoAP), Message Queuing Telemetry Transport (MQTT), User Datagram Protocol (UDP), Transport Control Protocol (TCP), Short Message Service (SMS), HTTP, WebSocket, ZigBee®, Thread® although it will be appreciated that these are examples of suitable protocols. Such communications are typically required to be secure to reduce the risk that malicious third parties gain access to the data, or to limit the access to data, by devices, servers or services. The device may use one or more security protocols to establish a secure communications session between entities for providing a secure channel or path for protecting data in communications. The security protocols may require credential data comprising one or more security credentials to establish a secure communications session. Examples of a security credential used in providing a secure communication session may include one or more of: a certificate (e.g. X.509 certificate), a cryptographic key (e.g. a shared symmetric key, public key, private key), whereby such credential data may be used by the device to authenticate (e.g. connect, establish secure communication session, register, enrol etc.) with one or more remote entities (e.g. a bootstrap server/server/services).

Exemplary security protocols may, for example, comprise Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), whereby TLS/DTLS requires various credential data to establish a secure communications session whereby the data in communications protected by TLS/DTLS may be encoded as plain text, binary TLV, JSON, CBOR, or any other suitable data exchange format.

The device 2 further comprises processing circuitry 12 for controlling various processing operations performed by the device 2.

The device 2 may further comprise input/output (I/O) circuitry 14, such that the device 2 can receive inputs (e.g. user inputs, sensor inputs, measurement inputs etc.) and or generate outputs (e.g. audio/visual/control commands etc.).

The device 2 further comprises storage circuitry 16 for storing data whereby the storage circuitry 16 may comprise volatile and/or non-volatile memory.

Figure 2a illustratively shows an example architecture 20 which illustrates a client-server relationship between the device 2 and servers 4/6. Figure 2b illustratively shows a schematic diagram of an object hierarchy model of device 2.

The device 2 comprises client 21 which may be integrated as a software library or a built-in function of a module and which is used in communications with the Server 4. The client 21 may be an LwM2M client.

Logical interfaces may be defined between the client 21 and servers 4/6, and four logical interfaces are depicted in Figure 2a, namely: • "Bootstrapping" interface enables headless device management, whereby this interface is used to configure the device to access one or more servers;

• 'Registration' interface may be used to perform and maintain registration with one or more servers and de-register from one or more servers.

• 'Device management and service enablement' interface may be used by one or more servers to access object(s), object instances and resources available at the device 2.

• 'Information Reporting' interface may be used to enable one or more servers to observe any changes in a resource on device 2, and for receiving notifications when new values are available.

This list of logical interfaces is exemplary only and additional, or alternative, logical interfaces between the client 21 and servers 4/6 may be provided, for example, in accordance with the OMA LwM2M specification.

The device 2 comprises various resources 22, which can be read, written, executed and/or accessed by the Server 4 or one or more further servers/services.

As an illustrative example, a resource comprises a value (e.g. generated by circuitry on the device). A relying party such as an application server 7a-7n may, via Server 4, request the value from the device 2 (e.g. with a REPORT request), whereby the requested value is read and reported back to the application server by the Server 4.

As a further illustrative example, a resource may comprise credential data provisioned at manufacture (e.g. during a factory provisioning process) or during a communication session with a bootstrap server, and subsequently used to register with the Server 4.

As depicted in Figure 2b, the resources 22 may be further logically organized into objects 24, whereby each device 2 can have any number of resources, each of which is associated with a respective object 24.

A set of objects on device 2 may include, for example:

• A 'security object' to handle security aspects between the device and a server;

• A 'server object' to define data and functions related to a server;

• An 'access control object' to define for each of one or more permitted servers the access rights the one or more permitted servers have for each object, object instance, resource, or resource instance on the device 2;

• A 'device object' to detail resources on the device 2. As an example, the device object may detail device information such as manufacturer, model, power information, free memory and error information;

• A 'connectivity monitoring object' to group together resources on the device 2 that assist in monitoring the status of a network connection;

• A 'firmware update object' enables management of firmware which is to be updated, whereby the object includes installing firmware, updating firmware, and performing actions after updating firmware.;

• A 'location object' to group those resources that provide information about the current location of the device 2;

• A 'connection statistics object' to group together resources on the device 2 that hold statistical information about an existing network connection;

In embodiments device 2 may have one or more instances of an object, three of which are depicted for object 1 as 24a, 24b and 24c in Figure 2b. As an illustrative example, a temperature sensor device may comprise two or more temperature sensors, and the device 2 may comprise a different device object instance for each temperature sensor.

In embodiments a resource may also comprise one or more resource instances as depicted as 22, 22a, 22b in Figure 2b.

In embodiments the objects, object instances, resources and resource instances are organised in an object hierarchy where each of the objects, object instances, resources and/or resource instances are elements of the object hierarchy, and whereby the device can enumerate the different elements of an object hierarchy using one or more characters (e.g. a text string; alphanumeric text, binary etc.)

Figure 2c shows one simplified example of a portion of such an object hierarchy 40, with omissions marked by elision marks (...). In Figure 2c, object 0 instance 2 is shown as having a single instance of resource 0 (that is, resource 0 instance 0), and two instances of resource 5 (that is, resource 5 instance 0 and resource 5 instance 1). The elements of the hierarchy are further marked with a hierarchy notation showing the levels and elements within levels using a slash separator. It will be clear to one of ordinary skill in the art that this is merely one example of a hierarchy notation and is not intended to limit the structure of the hierarchies available using the present techniques. It will also be clear to those of skill in the art that real-world implementations of such hierarchies will be much larger, and that only a very simple example has been shown here.

In the hierarchy shown in Figure 2c, an object may represent an LwM2M object. Instances of such objects are created according to the requirements of the system being implemented. Thus, for example, in a system for monitoring heating and cooling in a group of buildings, a Temperature object may be defined having instances for each of the buildings. The Temperature object instances may be defined to comprise resources, such as a Current Temperature resource, a Maximum Temperature resource and a Minimum Temperature resource, and each resource may further comprise instances for various temperature sensors.

On registration with a server, a device may then enumerate those elements of an object hierarchy which are to be registered using a suitable identifier, such as a universal resource indicator (URI), in the form:

• /{Object ID}/{Object Instance}/{Resource ID} e.g. /3/0/1.

As such, the objects, object instances, resources and resource instances on a device may be remotely accessed/managed by, for example, software hosted on a server (e.g. a bootstrap server, Server 4) or an application running as part of a service 5.

In an embodiment the Server 4 comprises, or has access to a resource directory (depicted as resource directory 30 in Figure 1) at the device management platform 8 (as depicted in Figure 1), whereby details for resources of various devices are stored in the resource directory 30. Additionally, or alternatively, the server 4 may have a local resource directory comprising only details of the resources of devices with which that server communicates.

Thus, the resource directory 30 is a registry of the elements of the object hierarchy on one or more devices registered with one or more servers. In embodiments the resource directory 30 may be realized using a processor and a storing device such as a hard disc drive and a suitable application, a database application in a computer or it may be realized using cloud computing.

The server 4 registers the device by storing the identified objects, object instances, resources and/or resource instances of the device in the resource directory 30. Once stored in the resource directory 30 the identified objects, object instances, resources and/or resource instances of the device can be looked up and accessed as required by other entities, such as applications 7a-7n.

In embodiments an entity relying on data stored at or generated by a device may require verification that the data and or the device itself is trustworthy before performing an action. For example, the entity may use the data to determine, for example:

• whether the device is genuine/authentic before establishing a secure communications session with the device or consuming the application data generated thereby;

• whether the device has the expect software installed thereon;

• whether the device is operating as expected.

Using the present techniques, device 2 (hereafter "attestor device") performs an attestation operation to generate an attestation token having one or more attestation token claims, where the attestation token claims allow an entity (hereafter "relying party") determine whether or not to trust the device and/or the data generated thereby. A device may use CBOR or JSON format to express the attestation token claims, although the claims are not limited in this respect.

Each attestation token claim comprises information relating to the attestor device or the data generated thereby. For example, an attestation token claim may comprise information for:

• identifying the attestor device itself (e.g. a unique identifier such as a universally unique identifier (UUID) or globally unique identifier (GUID);

• identifying the manufacturer of the chip and/or the attestor device;

• listing the software present on the attestor device including different versions of the software;

• indicating the attestor device boot state and debug state (e.g. whether the attestor device booted securely, whether debug mode is enabled, whether debug ports disabled);

• geographic position location (e.g. based on GPS, WiFi, cell tower or some combination);

• versions, measurements and/ or integrity checks of running software (e.g. Measurements of running software, usually hashes of the code);

• preventing replay and reuse of the attestation token. Such information may comprise a nonce (e.g. random number or pseudorandom number) received from an entity requesting the attestation token (hereafter "requestor party"), whereby the nonce is returned in the attestation token as an attestation token claim;

• providing an indication of freshness, where, in an illustrative example, an attestation token may comprise a time value generated using a time synchronisation protocol, where the time value is included in the attestation token as an attestation token claim. A relying party can then, using the time value, evaluate the freshness of the attestation token against a freshness policy (e.g. locally defined at the relying party);

• responding to a challenge set by the relying party or another entity.

The attestation token may be cryptographically signed by the attestor device (e.g. using a cryptographic key (e.g. a private key or symmetric key) provisioned on the attestor device (e.g. at bootstrap or manufacture), such that the relying party can verify the signature on the attestation token (e.g. using a corresponding key) to determine that it was generated by the attestor device. In embodiments, a header in the attestation token may identify the signing algorithm and the signing key to be used for verification.

On receiving an attestation token generated by an attestor device, a relying party may determine whether or not to trust the attestor device/the data in the attestation token by relaying the attestation token to an attestation service (not shown) for verification, and receiving a verification decision in response (e.g. approved/not approved). In other embodiments, the relying party may itself verify the attestation token to determine whether or not to trust the information therein.

Figure 3a depicts an illustrative example of a block diagram depicting an attestor device 2 generating an attestation token and further depicts the objects, object instances and resources allocated at the attestor device 2 to generate the attestation token. Figure 3b depicts an example communication flow between the attestor device 2, requestor 4 and relying party 7.

At S5, a relying party 7 (e.g. an application) requires attestation information from attestor device 2 and sends a request to a requestor 4.

The requestor 4 determines whether the request from the relying party is authorised and, when determined to be authorised, sends, at S10, a request to the attestor device 2 for the attestation information. As depicted in Figure 3a the request comprises a "create" command (or request) targeted at the attestation object 52. The "create" command invokes a create operation at the attestor device 2, to cause the attestor device 2 to allocate an attestation object instance and one or more attestation resources in the attestation object of the object hierarchy model at the attestor device 2. As will be appreciated, the attestor device 2 and requestor 4 may establish a secure communications session using a suitable protocol (e.g. TLS/DTLS) to securely communicate with one another prior to the "create" command being transmitted.

At S15 the attestor device 2 determines if the requestor 4 has the necessary access rights to invoke the "create" operation, for example by verifying access control parameters defined for the requestor 4. As depicted in Figure 3a, the attestor device 2 may check the access right of the ACL Resource Instance corresponding to this requestor party 4 located in the Access Control Object Instance 54 associated with the attestation object 52.

At S20, when it is determined the requestor has the necessary access rights, the attestor device 2 performs the create operation and allocates attestation object instance and attestation resource(s), where the attestation resources depicted in Figure 3a comprise nonce resource 58 and attestation token resource 60. In another embodiment, the attestation resource 58 may, additionally or alternatively, be populated with a time value time generated using a time synchronisation protocol.

The attestor device 2 allocates the newly instantiated object instance and attestation resources a unique identifier which the attestor device 2 can use to enumerate the respective locations thereof. In embodiments the requestor 4 may specify the identifiers to be allocated to the respective attestation object instance and attestation resources. Alternatively, the attestor device 2 may itself allocate the identifiers.

In embodiments the requestor 4 sends the "create" request in a TLV ((Type-Length-Value) format (as generally depicted in Figure 3a using numeral 62), where the attestor device 2 allocates and populates the nonce resource with values specified in the TLV create request.

Population of the nonce resource triggers, at S25, the allocation of the attestation token resource 60 by the attestor device 2.

At S30 the attestor device 2 registers the newly dynamically allocated attestation object instance and attestation resources with the resource directory 30 by enumerating those elements using the specified identifiers. Such a registration may be performed by the attestor device 2 directly with the resource directory 30, or via another entity such as the requestor 4 as depicted in Figure 3b. Registering the dynamically allocated attestation object instance and attestation resources at the resource directory allows the requestor 4 (or another authorised entity) to determine the location of the attestation resource(s).

At S35 the attestor device 2 generates the attestation token and populates the attestation token resource with the attestation token, where the attestation token includes attestation token claims. The format of the attestation token and the attestation token claims to be included in the attestation token may be specified by instructions provisioned on the attestor device 2. Such instructions may be provisioned by the manufacturer or during a bootstrap process. In a further example, the format of the attestation token and the attestation token claims to be included in the attestation token, may be specified by the requestor 4 (e.g. during HTTP/CoAP content negotiation, or custom query parameters (e.g. as part of the "create" request or a subsequent instruction)).

At S40 when the attestation token resource is populated with the attestation token, the attestor device 2 sends a signal or trigger to the requestor 4 to inform or notify the requestor 4 that the attestation token is available to access at the attestation token resource. In some embodiments the trigger is in response to an "observe" or "notify" request which the requestor 4 previously issued for the attestor device 2 to inform the requestor 4 when the attestation token resource 60 is updated with a new value.

At S45, the requestor accesses the attestation token at the location specified by the attesting device 4 (e.g. as at S30) and at S50 the requestor 4 sends the attestation token to the relying party 7 for verification. Such access may comprise sending a "read" request to the attestor device which includes a URI of the attestation token resource.

Following a successful access operation by the requestor 4, the requestor can issue a "delete" request to delete the object instances and associated resource(s) instantiate which were allocated by the attestor device 2.

Thus, the requestor 4 can invoke the creation of an attestation token by the attestor device 2 and can access the attestation token at the attestor device 2 on an asynchronous basis. Such functionality may be useful for constrained devices (e.g. constrained processing, communications or energy capabilities) or for devices operating in a constrained environment (e.g. an environment with relatively low bandwidth). For example, an attestor device 2 may go through a regular (or ad hoc) sleep/wake cycle to save energy, whereby the requestor may be aware when the attestor device is awake and can request the attestor device 2 perform the create operation in a first communications session during which the attestor device 2 is awake, disconnect and then establish a further secure communication session when the attestor device 2 is awake and access the attestation token.

The attestor device 2 can process multiple requests from the requestor (or other requestors) in parallel and the device can dynamically allocate attestation object instance and attestation resource(s) per request.

As will be appreciated, the transactions between the attestor device and requestor in the asynchronous model may be application programming interface (API) transactions which are decoupled from the underlying transport protocol communication sessions. Such decoupling may be achieved using a Representational state transfer (REST)ful pattern where, for example, ad-hoc attestation resources (e.g. nonce and attestation token resources) are dynamically created to hold transaction state across multiple/responses at the CoAP transport level.

Figure 4a depicts an illustrative example of a block diagram depicting an attestor device 2 generating attestation tokens for different requestors 4(l)/4(2) and further depicts the objects, object instances and resources allocated at the attestor device to generate the attestation token for relying parties 7(l)-7n;

Figure 4b depicts an example communication flow between the attestor device, requestors 4(l)/4(2) and relying parties, two of which 7(l)/7(2) are depicted in Figure 4b.

In the attestor device 2 of Figure 4a, attestation object 152 is allocated in the object hierarchy model, where the attestation object 152 has one or more attestation object instances 156(1) to 156(n), and each attestation object instances has a nonce resource 158 and attestation token resource 160 allocated in the object hierarchy model.

In the present embodiment, the attestation object 152, attestation object instances 156(1) to 156(n), nonce resources 158(1) to 158(n) and attestation token resources 160(1) to 160(n) are statically allocated at the attestor device (e.g. during a bootstrap process), and these dynamically allocated elements in the object model hierarchy are registered with device directory (not shown in Figures 4a or 4b).

At S105a, a relying party 7a requires attestation information from attestor device 2 and sends a request to requestor 4(1).

The requestor 4(1) determines whether the request from the relying party 7a is authorised and, when determined to be authorised, sends, at SllOa, a request to the attestor device 2 for attestation information.

As depicted in Figure 4a the request comprises a "write" command targeted at the nonce attestation resource 158(1), where the "write" command invokes a write operation where the attestor device writes nonce values specified in the write command to the nonce attestation resource 158(1).

At S115a the attestor device 2 determines if the requestor 4(1) has the necessary access rights to invoke the "write" operation, for example by verifying access control parameters defined for the requestor 4(1). As depicted in Figure 4a, the attestor device 2 may check the access right of the ACL Resource Instance corresponding to this requestor 4(1) located in the Access Control Object Instance 154a associated with the attestation object 156(1).

At S120a, when it is determined the requestor 4(1) has the necessary access rights, the attestor device 2 performs the write operation and populates the nonce attestation resource 158(1) with one or more values specified by the requestor 4(1). In another embodiment, the attestation resource 158(1) may be populated with a time value time generated using a time synchronisation protocol.

At S125a, when the attestation resource 158(1) is populated with the specified information, the attestor device 2 generates an attestation token, where the device includes attestation token claims as specified by instructions provisioned on the attestor device 2 and populates the attestation token resource 160(1) with the attestation token, where the attestation token includes attestation token claims. The format of the attestation token and the one or more attestation token claims to be included in the attestation token may be specified by instructions provisioned on the attestor device 2 (e.g. at manufacture or during a bootstrap process). In a further example, the format of the attestation token and the one or more attestation token claims to be included in the attestation token, may be specified by the requestor 4a (e.g. as part of the "write" request or a subsequent instruction). At S130a when the attestation token resource is populated with the attestation token, the attestor device 2 sends a signal or trigger to the requestor 4(1) to inform or notify the requestor 4(1) that the attestation token is available to access at the attestation token resource. In some embodiments the trigger is in response to an "observe" or "notify" request which the requestor 4(1) previously issued for the attestor device 2 to inform the requestor 4(1) when the attestation token resource 160(1) is updated with a new value.

At S135a, the requestor 4(1) accesses the attestation token at the location specified by the attestor device 2 by sending, for example, a "read" request targeted at the location of the attestation token resource 160(1).

At S140a the requestor 4(1) sends the attestation token to the relying party 7a for verification.

The attestor device 2 may receive and process two or more requests from different requestors. For example, as depicted in Figure 4b, a second relying party 7b requires information from attestor device 2 and, at S105b, sends a request to a requestor 4b.

The requestor 4(2) determines whether the request from the relying party 7b is authorised and when determined to be authorised sends, at SI 10b a request to the attestor device 2 to generate the attestation information.

As depicted in Figure 4a the request comprises a "write" command targeted at the nonce attestation resource 158(2), where the "write" command causes the attestor device 2 to write values specified therein to the nonce attestation resource 158(2).

At S115b the attestor device 2 determines if the requestor 4(2) has the necessary access rights to request the "write" operation, for example by verifying access control parameters defined for the requestor 4(2). As depicted in Figure 4a, the attestor device 2 may check the access right of the ACL Resource Instance corresponding to this requestor 4(2) located in the Access Control Object Instance 154b associated with the attestation object 156(2).

At S120b, when it is determined the requestor 4a has the necessary access rights, the attestor device 2 performs the write operation and populates the nonce attestation resource 158(2) with one or more values specified by the requestor 4b. In another embodiment, the attestation resource 158(2) may be populated with a time value time generated using a time synchronisation protocol. At S125b, when the attestation resource 158(2) is populated with the specified information, the attestor device 2 generates an attestation token, where the device includes attestation token claims as specified by instructions provisioned on the attestor device 2 and populates the attestation token resource 160(2) with the attestation token, where the attestation token includes one or more attestation token claims. The format of the attestation token and the one or more attestation token claims to be included in the attestation token may be specified by instructions provisioned on the attestor device 2 (e.g. at manufacture or during a bootstrap process). In a further example, the format of the attestation token and the one or more attestation token claims to be included in the attestation token, may be specified by the requestor 4b (e.g. as part of the "write" request or a subsequent instruction).

At S130b when the attestation token resource is populated with the attestation token, the attestor device 2 sends a signal or trigger to the requestor 4(2) to inform or notify the requestor 4(2) that the attestation token is available to access at the attestation token resource. In some embodiments the trigger is in response to an "observe" or "notify" request which the requestor 4b previously issued for the attestor device 2 to inform the requestor 4b when the attestation token resource 160(2) is updated with a new value.

At S135b, the requestor 4(2) accesses the attestation token at the location specified by the attestor device 2 by sending, for example, a "read" request targeted at the location of the attestation token resource 160(2).

At S140b the requestor 4(2) sends the attestation token to the relying party 7b for verification.

Thus, according to the present techniques the requestor 4(2) can request that the attestor device generate an attestation token and can access the attestation token when required in an asynchronous manner, and the attestor device 2 may also process requests for attestation tokens from two or more requestors.

When the attestor device 2 is processing a request from a first requestor, and it receives a request from a second requestor before completing the transaction (i.e. before storing the attestation token), the attestor device 2 can terminate an on-going transaction to process a subsequent request determined to take priority, or the attestor device may return a busy signal to the requestor that issued the subsequent request. When the attestor device populates a nonce attestation resource, the corresponding attestation token resource may be emptied if it is already populated (e.g. with an attestation token from a previous transaction).

The models depicted in Figures 3a and 4b may be considered RESTful models, and the requestor may communicate with the attestor device using a REST interface.

Figure 5 shows a flow diagram of an example process 200 of an attestor device generating an attestation token in response to a request from a requestor.

At S200, the process starts.

At S210, the attestor device receives a request for attestation information from a requestor. The request may, for example, comprise one or more commands which causes the attestor device to invoke actions resulting in generation of an attestation token. Such a command may, for example, be a "create" or "write" command although the claims are not limited in this respect.

At 220, the attestor device determines whether the request is authorised. Such a determination may be made using any suitable techniques, such as verifying access rights for the requestor. When the request is determined to be unauthorised then the attestor device may inform the requestor or terminate communications, and the process ends.

When the request is determined to be authorised, at S230 the attestor device generates an attestation token comprising attestation information, where the attestation information may comprise one or more attestation token claims.

At S240, the attestor device stores the attestation token in storage. In embodiments the attestor device populates a resource allocated thereon with the attestation token, where the resource is an attestation resource in a device object- resource hierarchy. In embodiments the attestation resource is dynamically allocated by the attestor device in response to the request. Additionally, or alternatively, the attestation resource may be pre-allocated on the device prior to the request, for example allocated at manufacture or during a bootstrap process.

At S250 the attestor device informs or notifies the requestor (or other entity specified to the device (e.g. as part of the request)) that the attestation token is available to access and the attestor device waits for further instructions in respect of the attestation token. In the meantime, the attestor device may, for example, perform other functions as part of its normal operation or it may go to sleep. At S260, the attestor device receives a request to access the attestation token. The access request may be received from the requestor that sent the initial request for attestation information or the access request may come from another entity (e.g. a relying party).

At 270, the attestor device determines whether the access request is authorised. Such a determination may be made using any suitable techniques, such as verifying access rights for the entity that made the access request. If the access request is determined to be unauthorised then the attestor device may inform the entity that made the access request and/or terminate communications, and the process ends.

When the access request is determined to be authorised, at S280 the attestor device provides the entity that made the access request with access to the attestation token.

A relying party can then use the attestation token in an appropriate manner, for example by sending it to an attestation service.

At 290 the process ends.

The embodiments described above generally describe an attestor device generating an attestation token and an entity accessing the attestation token on an asynchronous basis, where the attestor device stores the attestation token until it is accessed.

Figure 6a shows an illustrative example of a block diagram depicting an attestor device 2 generating an attestation token which is accessed on a synchronous basis. Figure 6b depicts an example communication flow between the attestor device 2, a requestor 4 and a relying party 7.

At S305, a relying party 7 (e.g. an application) requires attestation information from attestor device 2 and sends a request to requestor 4.

The requestor 4 determines whether the request from the relying party is authorised, and when determined to be authorised, sends, at S310, a request to the attestor device 2 for attestation information. As will be appreciated, the attestor device 2 and requestor 4 may establish a secure communications session using a suitable protocol (e.g. TLS/DTLS) to securely communicate with one another prior to the request for attestation information being transmitted.

As depicted in Figure 6a, the request comprises an "execute" command (or request) targeted at the attestation token resource 360. The "execute" command invokes an execution operation at the attestor device 2, to cause the attestor device 2 to generate the attestation token and send the attestation token to the requestor 4 (and/or to send the attestation token to another specified entity).

At S315 the attestor device 2 determines if the requestor 4 has the necessary access rights to invoke the "execute" operation, for example by verifying access control parameters defined for the requestor 4. As depicted in Figure 6a, the attestor device 2 may check the access right of the ACL Resource Instance corresponding to this requestor party 4 located in the Access Control Object Instance 354 associated with the attestation object before performing the requested operation.

When it is determined that the requestor 4 has the necessary access rights, the attestor device 2, at S320, generates an attestation token which includes one or more attestation token claims in response to the execute operation.

The format of the attestation token and the attestation token claims to be included in the attestation token may be defined by instructions provisioned on the requestor 4 (e.g. at manufacture or during bootstrap). For example, the "execute" request depicted in Figure 6a comprises a nonce value, where an attestation token claim in the attestation token comprises the nonce value and instructions define how the nonce should be included as an attestation token claim. Additionally, or alternatively, the format of the attestation token and the attestation token claims to be included in the attestation token may be specified by the requestor 4 (e.g. as part of the "execute" command or a subsequent instruction).

At S325 the attestor device 2 sends the attestation token to the requestor 4. As depicted in Figure 6a, the attestor device 2 sends the attestation token as part of a response code 2.04 when using CoAP.

Thus, the requestor 4 obtains the attestation token in a synchronous manner from the attestor device 2, where the attestation token is provided to the requestor 4 as part of the execute operation.

At S330, the requestor 4 provides the attestation token to the relying party 7. In a further embodiment, the attestor device 2 may provide the attestation token to an entity other than the requestor 4 e.g. the attestor device 2 may provide the attestation token directly to the relying party 7.

As will be appreciated, the transactions between the attestor device and requestor in the synchronous model may be application programming interface (API) transactions which are isolated from one another at the transport level, and there is no requirement to link application state across multiple transport communication sessions. The attestation tokens generated by the attestor device may not hold any application state, rather an attestation resource used to store an attestation token may function as a remote procedure call (RPC) endpoint. When a transport communication session completes (e.g. when a secure communication channel session is ended) the resource(s) allocated to the API transaction can be reclaimed by the device to free up the resource(s).

Although the requestor above is generally described as a LwM2M server, the claims are not limited in this respect and in embodiments the requestor may be a server which follows a standard/protocol set by the Open Connectivity Foundation or Open Interconnect Consortium or any other suitable device.

Embodiments of the present techniques may provide implementations which conform to the Open Mobile Alliance Lightweight Machine to Machine Technical Specification, Version 1.0 and to one or more revision(s) thereof, including, for example, Versions 1.0.2, 1.1 and 1.3. It will be appreciated that the claims are not limited in this respect, and embodiments may provide implementations which conform to other protocols, such as Bluetooth Low Energy (BLE).

Embodiments of the present techniques also provide a non-transitory data carrier carrying code which, when implemented on a processor, causes the processor to carry out the methods described herein.

The techniques further provide processor control code to implement the above-described methods, for example on a general purpose computer system or on a digital signal processor (DSP). The techniques also provide a carrier carrying processor control code to, when running, implement any of the above methods, in particular on a non-transitory data carrier or on a non-transitory computer- readable medium such as a disk, microprocessor, CD- or DVD-ROM, programmed memory such as read-only memory (firmware), or on a data carrier such as an optical or electrical signal carrier. The code may be provided on a (non-transitory) carrier such as a disk, a microprocessor, CD- or DVD-ROM, programmed memory such as non-volatile memory (e.g. Flash) or read-only memory (firmware). Code (and/or data) to implement embodiments of the techniques may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as Verilog™ or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate, such code and/or data may be distributed between a plurality of coupled components in communication with one another. The techniques may comprise a controller which includes a microprocessor, working memory and program memory coupled to one or more of the components of the system.

Computer program code for carrying out operations for the above-described techniques may be written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages. Code components may be embodied as procedures, methods or the like, and may comprise sub-components which may take the form of instructions or sequences of instructions at any of the levels of abstraction, from the direct machine instructions of a native instruction set to high-level compiled or interpreted language constructs.

It will also be clear to one of skill in the art that all or part of a logical method according to the preferred embodiments of the present techniques may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the above-described methods, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using fixed or transmittable carrier media.

In an embodiment, the present techniques may be realised in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system or network and operated upon thereby, enable said computer system to perform all the steps of the above-described method.

Those skilled in the art will appreciate that while the foregoing has described what is considered to be the best mode and where appropriate other modes of performing present techniques, the present techniques should not be limited to the specific configurations and methods disclosed in this description of the preferred embodiment. Those skilled in the art will recognise that present techniques have a broad range of applications, and that the embodiments may take a wide range of modifications without departing from any inventive concept as defined in the appended claims.

Claims

1) A computer-implemented method of generating an attestation token on an attestor device, the method performed at the attestor device comprising: receiving, from a first requestor, a request for device attestation information; determining, whether the request for device attestation information is an authorised request; when it is determined that the request is an authorised request: generating a first attestation token comprising the attestation information in response to the received request for device attestation information; storing the first attestation token in storage at the attestor device; notifying the first requester that the first attestation token is available to access at the storage; receiving, from the first requestor, an access request to access the first attestation token; providing the first requestor with access to the first attestation token in response to the access request.

2) The method of claim 1, further comprising: disconnecting from the first requestor after the request for device attestation information is received.

3) The method of any preceding claim, wherein the method further comprises: determining, whether the request to access the attestation token is an authorised request; providing the first requestor with access to the first attestation token when it is determined that the request for the first attestation token is an authorised request. 4) The method of any preceding claim, where the attestor device comprises an object hierarchy.

5) The method of claim 4, where the attestor device comprises an attestation object, one or more attestation object instances and one or more attestation resources of the object hierarchy.

6) The method of claim 5, where storing the first attestation token in storage comprises: writing the first attestation token to a first attestation resource of the one or more attestation resources.

7) The method of claim 6, where the first attestation resource is allocated by the attestor device.

8) The method of claim 7, further comprising: registering the device allocated first attestation resource with the first requestor or with a further entity.

9) The method of claim 8, where registering the device allocated first attestation resource comprises: enumerating the first attestation resource using one or more identifiers.

10) The method of claim 9, where the one or more identifiers comprises a universal resource identifier.

11) The method of any preceding claim, further comprising: receiving, from a second requestor, a further request for device attestation information; determining, whether the further request is an authorised request; when it is determined that the further request is an authorised request: generating a second attestation token in response to the received further request; storing the second attestation token in storage at the attestor device; notifying the second requester that the first attestation token is available to access at the storage; receiving, from the second requestor, an access request to access the second attestation token; providing the second requestor with access to the second attestation token in response to the request to access request.

12) The method of claim 11, where storing the second attestation token in storage comprises: writing the second attestation token to a second attestation resource of the one or more attestation resources.

13) The method of claim 12, where the second attestation resource is allocated by the attestor device.

14) The method of any preceding claim, where determining, whether the request for device attestation information is an authorised request comprises: verifying access control information in the request for device attestation information.

15) The method of any preceding claim, where the request for device attestation information comprises a nonce.

16) The method of any preceding, where the attestor device is an LwM2M device and/or where the first requestor is an LwM2M server.

17) The method of any proceeding claim, where the attestation token comprises one or more attestation token claims.

18) The method of any preceding claims where the format of the attestation token is specified by one of: instructions on the device or instructions received from the requestor. 19) A device comprising: processing circuitry; storage circuitry; and communication circuitry; and wherein the device is to perform the method of any one of claims 1 to 18.

20) A computer-implemented method of obtaining attestation information from an attestor device, the method performed at a requestor apparatus comprising: transmitting, to the attestor device, a request for attestation information; receiving, from the attestor device a notification that an attestation token comprising the attestation information is available to access at storage on the attestor device; transmitting, to the attestor device, an access request to access the attestation token; accessing the attestation token in response to the access request; providing, to a relying party, the attestation token.

21) The method of claim 20 comprising: establishing a first communication session with the attestor device; transmitting the request for the attestation information during the first communication session. establishing a second communication session with the attestor device; transmitting the access request during the second communication session.

22) A non-transitory computer readable storage medium comprising code which when implemented on a processor causes the processor to carry out the method of any one of claims 1 to 18 or 20 to 21.

23) An apparatus comprising: processing circuitry; and communication circuitry; and wherein the apparatus is to perform the method of any one of claims 20 to 21. 24) A system comprising: an attestor device; and a requestor; wherein the attestor device is to perform the method of any one of claims 1 to 18.

25) A method of generating an attestation token on a device having an object hierarchy model, the method performed at the device comprising: establishing a secure communication session with a requestor; receiving, from the requestor, a request for device attestation information, where the request is targeted at an attestation resource of the object hierarchy; determining, whether the request is an authorised request; when it is determined that the request is an authorised request, generating with the attestation resource an attestation token comprising the attestation information in response to the received request; sending the attestation token to the requestor device during the secure communication session.