WO2023237197A1

WO2023237197A1 - Attested one-time on-device secure api authorization

Info

Publication number: WO2023237197A1
Application number: PCT/EP2022/065707
Authority: WO
Inventors: Qiming Li
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-06-09
Filing date: 2022-06-09
Publication date: 2023-12-14

Abstract

In some examples, a method for application programming interface, API, invocation comprises sending, by a first application stored in a device, an authorisation initialisation request to an authorisation server, generating, by the authorisation server, a challenge value for transaction authorisation and transmitting the challenge value to the first application, sending, by the first application, the challenge value to a second application stored in the device, the second application comprising the API, wherein the second application comprises a counter, generating, by the second application, an attestation comprising the challenge value and transmitting the attestation to the first application, transmitting, by the first application, the attestation to the authorisation server, validating, by the authorisation server, the attestation, and generating, by the authorisation server, a one-time API authorisation and transmitting the authorisation to the first application to thereby enable the first application to invoke the API.

Description

ATTESTED ONE-TIME ON-DEVICE SECURE API AUTHORIZATION

Technical Field

The present invention relates generally to a device, a server and an improved mechanism for secure API authorisation and invocation.

Background

During manufacturing of computing devices, it is often required that some secret key materials and data be provisioned to the devices securely via a provisioning application programming interface (API) provided by the software hosted on the computing devices. Such an API needs to be protected carefully so that it will not be abused after the devices have been manufactured. In some cases, such provisioning process is required only once during the lifetime of the computing device, and hence can safely be disabled permanently after the provisioning is completed in the factory where the device was manufactured. However, in many cases, the provisioning process needs to be repeated, for example, due to device repair or data damage. In such cases, the disabled API may be re-enabled by authorised personnel in a service centre.

The computing device may have a secure region, such as a Trusted Execution Environment (TEE) or a Secure Element (SE), where a secure application is hosted, and a normal region, such as a Rich Execution environment (REE), where a corresponding provisioning application is hosted. The API provided by the secure application cannot be invoked directly from the outside of the computing device. In order to provision keys and data to the secure application during manufacturing, special factory equipment may be used to connect to the device and invoke an API provided by the provisioning application, which in turn invokes an API provided by the secure application to complete the provisioning process. The factory equipment may be a special purpose computing device, or can be built using general purpose computers.

In order to prevent the provisioning API of the secure application from being abused by attackers, it is usually required to disable the provisioning API of both the secure application and the provisioning application after manufacturing. To allow the provisioning process to be repeated in a service centre, a special authorisation is required to boot the device into a service mode, which allows the provisioning API to be re-enabled. The authorisation can be provided using a hardware token/dongle that needs to be connected to the service centre equipment while booting the device, or using cryptographic keys and certificates issued to the service centre equipment. In such case, the authorisation is typically bound to the hardware token, or the service centre equipment, and can be used on any device that needs repair. Unfortunately, providing authorisation in such manner does not prevent abuse by the service centre staff, and does not allow provisioning to be performed outside the service centre.

Summary

An objective of the present disclosure is to provide a secure API authorisation and invocation method.

The foregoing and other objectives are achieved by the features of the independent claims.

Further implementation forms are apparent from the dependent claims, the description and the Figures.

A first aspect of the present disclosure provides a method for application programming interface, API, invocation, the method comprising sending, by a first application stored in a device, an authorisation initialisation request to an authorisation server, generating, by the authorisation server, a challenge value for transaction authorisation and transmitting the challenge value to the first application, sending, by the first application, the challenge value to a second application stored in the device, the second application comprising the API, wherein the second application comprises a counter, generating, by the second application, an attestation comprising the challenge value and transmitting the attestation to the first application, transmitting, by the first application, the attestation to the authorisation server, validating, by the authorisation server, the attestation, and generating, by the authorisation server, a one-time API authorisation and transmitting the authorisation to the first application to thereby enable the first application to invoke the API.

Accordingly, a protected API provided by a secure application in a secure region of a computing device can be authorised for one-time use when needed by ensuring that each invocation of the API requires an explicit one-time authorisation from a trusted server, so as to minimize the risks of API abuse. In an implementation of the first aspect, the method further comprises the steps of sending, by the first application, input data for API invocation to the second application, generating, by the second application, the attestation comprising the input data and transmitting the attestation to the first application, transmitting, by the first application, the input data to the authorisation server, and validating, by the authorisation server, the input data, wherein the one-time API authorisation comprises the input data. As such, the intended input data can be bound to the authorisation request, thereby improving security of the operation.

The input data may comprise a hash value. As such, the generated authorisation can only be used to invoke the API with the input data that would yield the same hash value, further improving security.

The authorisation server may store the generated challenge value for a predetermined amount of time. As such, a mechanism for ensuring that the generated attestation is new and not a replay of a previous attestation used for a previous authorisation request can be provided.

The step of validating the attestation may comprise at least one of validating a cryptographic signature using a public key included in the attestation, and verifying that the challenge value in the attestation matches the challenge value stored by the authorisation server. As such, the authorisation server can verify whether the received attestation is genuine, thereby improving security.

The attestation may comprise at least one of an identifier associated with the API, the challenge value, an identifier associated with the first application, a counter value, and a device identifier. As such, security can be improved by providing various metrics that can be used for validation/verification of the request.

The second application may store an attestation key, wherein the attestation is signed by the attestation key. As such, the validity of the attestation key can be checked, further improving security.

The one-time API authorisation may comprise an identifier associated with the API, a device identifier, an identifier associated with the first application, a counter value and the input data. As such, the one-time API authorisation can later be verified based on this data. The one-time API authorisation may be signed by the authorisation server using a private key of an asymmetric key pair, a public key of the asymmetric key pair known to the second application to thereby enable the second application to verify the signed authorisation. As such, the authorisation signature can be verified by the second application.

In response to receiving the authorisation initialisation request from the first application, the authorisation server may send an authentication request to the first application. The first application may provide authentication credentials to the authorization server to prove its authenticity, thereby protecting the authorisation service from abuse.

The method may further comprise the steps of sending, by the first application, the input data and the one-time API authorisation to the second application, validating, by the second application, the one-time API authorisation and the input data and processing the input data according to the API, and removing, by the second application, the received challenge value and incrementing the counter. As such, the authorisation cannot be repeatedly used, cannot be used for protected APIs other than the intended API, and cannot be used by other applications and/or devices other than the device hosting the second application that was involved in the authorisation process.

The method may further comprise the steps of sending, by the first application, a request for in-field provisioning to a provisioning server, and receiving, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning. As such, the factory provisioning API can be invoked in a secure way, such that each invocation requires explicit one-time authorisation from a trusted server.

The set of encrypted provisioning data may comprise a cryptographic key. As such, security can be improved.

A second aspect of the present disclosure provides a device comprising a processor, a memory coupled to the processor, the memory configured to store a first application and a second application, wherein the second application comprises an application programming interface, API, and a counter, the memory further configured to store program code executable by the processor, the program code comprising one or more instructions, whereby to cause the device to send, by the first application, an authorisation initialisation request to an authorisation server, receive, by the first application, a challenge value for transaction authorisation from the authorisation server, transmit the challenge value from the first application to the second application, generate, by the second application, an attestation comprising the challenge value and transmit the attestation to the first application, transmit the attestation from the first application to the authorisation server, and receive, by the first application, a one-time API authorisation from the authorisation server to thereby enable the first application to invoke the API.

Accordingly, a protected API provided by a secure application in a secure region of a computing device can be authorised for one-time use when needed by ensuring that each invocation of the API requires an explicit one-time authorisation from a trusted server, so as to minimize the risks of API abuse.

The program code may further comprise one or more instructions whereby to cause the device to send, by the first application, input data for API invocation to the second application, generate, by the second application, the attestation comprising the input data and transmit the attestation to the first application, and transmit, by the first application, the input data to the authorisation server for validation, wherein the onetime API authorisation comprises the input data. As such, the intended input data can be bound to the authorisation request, thereby improving security of the operation.

The attestation may comprise at least one of an identifier associated with the API, an identifier associated with the first application, a counter value, and a device identifier. As such, security can be improved by providing various metrics that can be used for validation/verification of the request.

The second application may be arranged to store an attestation key, wherein the attestation is signed by the attestation key. As such, the validity of the attestation key can be checked, further improving security.

The one-time API authorisation may comprise an identifier associated with the API, a device identifier, an identifier associated with the first application, a counter value and the input data. As such, the one-time API authorisation can later be verified based on this data. The second application may comprise a private key of an asymmetric key pair used by the authorisation server for signing the one-time API authorisation, wherein the second application is arranged to verify the signed authorisation. As such, the authorisation signature can be verified by the second application.

The program code may further comprise one or more instructions whereby to cause the device to send, from the first application, the input data and the one-time API authorisation to the second application, validate, by the second application, the one-time API authorisation and the input data, and process the input data according to the API, and remove, by the second application, the received challenge value and increment the counter. As such, the authorisation cannot be repeatedly used, cannot be used for protected APIs other than the intended API, and cannot be used by other applications and/or devices other than the device hosting the second application that was involved in the authorisation process.

The program code may further comprise one or more instructions whereby to cause the device to send, from the first application, a request for in-field provisioning to a provisioning server, and receive, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning. As such, the factory provisioning API can be invoked in a secure way, such that each invocation requires explicit one-time authorisation from a trusted server.

Brief description of the figures

Embodiments will now be described by way of example only with reference to the figures, in which:

Figure 1 schematically depicts a device, in accordance with an example embodiment;

Figure 2 schematically depicts a method for application programming interface (API) invocation, in accordance with an example embodiment;

Figure 3 schematically depicts a method for authorised API invocation, in accordance with an example embodiment;

Figure 4 schematically depicts a method for secure in-field provisioning, in accordance with an example embodiment.

Detailed Description Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

It is often possible to boot the device to be serviced or repaired into a special service mode in a service centre. Typically, this requires the device to be connected to service centre equipment (for example, a PC), with the authorisation given in the form of a hardware token or a dongle that is connected to the service centre equipment at the same time as the device. Such hardware tokens or dongles can be issued to all service centres that may repair or service the device. Alternatively, cryptographic keys and certificates can be issued to the service centre equipment instead of hardware tokens or dongles. In both cases, the authorisation is associated with the hardware token/dongle or the specific keys and certificates. Once such a token/dongle/key are acquired, any device can be booted into the service mode. As such, the hardware tokens and dongles or the keys and certificates required for certification must be kept in safe places to prevent abuse. However, this might not always be easy or possible due to accidental loss of the tokens/dongles, or compromised keys. Even if the problem of safekeeping of dongles/keys is resolved, this approach still restricts the repair (i.e. the enabling of the protected API) to be performed only at the authorised service centres. The approach cannot be used in a situation where authorised use of a protected API is required in-field for devices that are already deployed and cannot be taken to service centres.

Another common approach to authorise the use of an API is by checking the caller (i.e. the client) of the API. For example, in an operating system, an API may be provided in such a way that only applications that run as a privileged user (for example, the root user or an administrator) can make a call to the API. The roles application processes may assume can be determined in many ways, usually specific to the operating system. For example, in an Android device, applications installed in a system partition and signed by a particular system signing key may be considered to have the system privilege. This authorisation method can also be applied to protect secure APIs provided by secure applications running in the secure region of the device to allow only specific applications in the normal region to access such APIs. For example, in case of factory provisioning, the secure application may require that only the provisioning application from the normal region can invoke the provisioning API provided by the secure application.

However, process/application based authorisation methods place a heavy dependence on the integrity of the system. If the system is under attack, a malicious application may impersonate a high privilege application and the protected API may still be abused. Typically, the normal region of the device is more likely to be compromised compared with the secure region. If the normal region is compromised, the calling application cannot be reliably identified by the secure application. As a result, the secure API may be abused. Furthermore, even if the calling application can be identified reliably, there may still be risks that an authorised caller is also abused or exploited due to programming errors or attacks. In such cases, the secure may still be abused. According to an example, there is provided a mechanism for provision of a secure onetime API authorisation, such that a protected API provided by a secure application in a secure region of a computing device may be authorised for one-time use when needed, and that such authorisations cannot be circumvented or abused even when the normal region of the device is compromised.

Examples in the present disclosure can be provided as methods, systems or machine- readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

The present disclosure is described with reference to flow charts and/or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and/or additional blocks may be added. It shall be understood that each flow and/or block in the flow charts and/or block diagrams, as well as combinations of the flows and/or diagrams in the flow charts and/or block diagrams can be realized by machine readable instructions.

The machine-readable instructions may, for example, be executed by a machine such as a general-purpose computer, user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus (for example, a module implementing a comparator unit, or a firewall structure and so on) may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors.

Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor.

Figure 1 schematically depicts a device, in accordance with an example embodiment. The device 100 can be, for example, an electronic device such as a smartphone, tablet computer, smart watch, laptop computer, Intemet-of-Things (loT) device and others. The device 100 comprises a processor 103, and a memory 105 coupled to the processor 103 and configured to store a first application 109 and a second application 111, the second application 111 comprising an application programming interface (API) 113 and a counter 115, the memory 105 further configured to store instructions or program code 107, executable by the processor 103.

The second application 111 may be an application hosted in a secure region of the memory 105 of the device 100, providing the API 113 which needs to be protected. The second application 111 may have exclusive access to a secure attestation key and the secure monotonic counter 115. The first application 109 may be an application hosted in a normal region of the memory 105 of the device 100. The first application 109 may be used to invoke the protected API 113 provided by the second application 111.

The device 100 is arranged to send, by/from the first application 109, an authorisation initialisation request to an authorisation server. As such, the device 100 may initiate the process of obtaining a one-time authorisation from a trusted authorisation server.

The first application 109 is arranged to receive a challenge value for transaction authorisation from the authorisation server. The purpose of generating and sending the challenge value to the first application 109 is to ensure that the later-generated attestation is fresh and not a replay of a previous attestation for a previous authorisation request.

The challenge value is then transmitted from the first application 109 to the second application 111. The second application 111 generates an attestation comprising the challenge value acquired from the authorisation server and transmits the attestation to the first application 109. The second application 111 may store the challenge value so that it can later be used to validate the authorisation. The first application 109 transmits the attestation to the authorisation server. The first application 109 then receives a one-time API authorisation from the authorisation server to thereby enable the first application 109 to invoke the API 113.

The first application 109 may be further configured to send input data for API invocation to the second application 111. The second application 111 may generate the attestation comprising the input data and transmit the attestation to the first application 109. The first application 109 may transmit the input data to the authorisation server for validation. The one-time API authorisation may comprise the input data. The input data may comprise a hash value.

In other words, the first application 109 may send the challenge value and a hash value of the intended input data for API invocation to the second application 111. By sending the hash value of the intended input data, the second application 111 may bind the input data with the authorisation request if this is needed for the intended use case, so that the later-generated authorisation can only be used to invoke the API 113 with the input data that would yield the same hash value. If the input data is not known at the time of authorisation, or it is not necessary to bind the data to the authorisation request, the hash value can be omitted such that only the challenge value is sent from the first application 109 to the second application 111.

Furthermore, by transmitting the input data from the first application 109 to the authorisation server alongside the attestation, the authorisation decision may be based on the actual input data to be sent while invoking the API 113. The input data may be used to verify whether the invocation is a potential attack, for example if the input data is not genuine. As discussed above, if such checking is not possible or not needed, or such information is not available during authorisation, the data or the hash value of the data can be omitted.

The attestation generated by the second application 111 may comprise at least one of an identifier associated with the API, an identifier associated with the first application, a counter value of the counter, and a device identifier of the device. The identifier associated with the API may be used to differentiate between different APIs such that authorisation for one API (such as the API 113) cannot be used to invoke another API. The identifier associated with the first application may be utilised if the second application 111 allows multiple applications from a normal region (e.g. REE) of the device 100 to invoke protected APIs, such that an authorisation given to one application cannot be used by another application.

The counter value of the secure counter may be employed to ensure that the authorisations are one-time use only, by using the value to validate authorisations during API invocation. In case the authorisation process has never been performed in the device 100 before, the counter 115 may require initialisation before use. For example, the counter 115 may be set to have an initial value of 0, or any other fixed or random value, as long as the counter value can only be incremented but not decremented (i.e. the counter 115 is monotonic). The device identifier of the device 100 may be used to allow the authorisation server to identify the device that generated the attestation, such that the authorisation request may be rescheduled if needed. If privacy is of concern, the device identifier of the device 100 may be replaced with a device group identifier that allows validation without revealing the identity of the device 100.

The second application 111 may be arranged to store an attestation key. The second application 111 may be arranged to sign the generated attestation using the attestation key. The attestation key may comprise, for example, an asymmetric key pair. In such scenario, the attestation generated by the second application 111 may further comprise a public key of the attestation key and associated certificates issued by certificate authorities such that the validity of the attestation key can later be verified if needed.

The one-time API authorisation may comprise an identifier associated with the API, a device identifier, an identifier associated with the first application, a device identifier, an identifier associated with the first application, a counter value and the input data.

The second application 111 may comprise a private key of an asymmetric key pair used by the authorisation server for signing the one-time API authorisation. The second application 111 may be arranged to verify the authorisation signed by the authorisation server.

After receiving the one-time API authorisation from the authorisation server, the first application 109 may be arranged to send the input data and the one-time API authorisation to the second application 111. This starts the API invocation.

While it is possible for the API invocation to occur immediately after authorisation, it is also possible to obtain an authorisation in advance and only invoke the API 113 when it is actually needed. This is different from the solutions employed in the prior art, where authorisations may expire after a short period of time. One reason for this is that the secure regions in many electronic devices (TEE or SE) do not have reliable sources of time, relying on the unreliable normal region (REE) to know the current time. Furthermore, a device owner may obtain an authorisation to erase/replace critical information on the device before the device is transferred to a new owner, who then erases or replaces such information after the transfer is completed. Imposing a time constraint on such a transaction may not be desirable.

The second application 111 may validate the one-time API authorisation and the input data received from the first application 109, and process the input data according to the API 113 to generate a result. The validation by the second application 111 may comprise verifying a cryptographic signature of the authorisation with the public key known to belong to the authorisation server, verifying that the identifier associated with the API matches the API 113 that is being invoked, verifying that the device identifier or device group identifier matches the device 100, verifying that the identifier associated with the first application matches the identity of the first application 109, verifying that the challenge value matches the challenge value received by the second application 111, verifying that the hash value matches the hash value of the input data, and that the secure counter value matches the value of the secure counter 115.

By verifying the signature, the second application 111 can be certain that the authorisation was created by a trusted authorisation server. Verifying the identifier associated with the API/device/device group/application enables the second application 111 to ensure that the authorisation is indeed intended to be used on the device 100 and the specified API 113 by the actual calling application. Validating the challenge value and the secure counter value confirms whether the authorisation has been used before. If data hash is present in the authorisation, checking the hash value of the input data ensures that the input data has been checked by the authorisation server.

The second application 111 may then remove the received challenge value and increment the counter value of the counter 115 before sending the generated result back to the first application 109. Since the counter 115 is monotonic, its value can only increase and not decrease. Removing (or resetting) the challenge value and incrementing the counter 115 ensures that all previously generated and used authorisations cannot be used again. As such, the API authorisation is allowed to be used once only, providing fine-grained access control. In some scenarios, a need to provision additional data into a device that has already been deployed in the field may arise. This may require invoking a protected factory provisioning API that has been disabled after the device has been manufactured. As such, the first application 109 (stored in the normal region of the device 100) may be configured to send a request for in-field provisioning to a provisioning server. The device 100 may then receive, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning. This process will be described in more detail in relation to Figure 4.

Figure 2 schematically depicts a method for application programming interface (API) invocation, in accordance with an example embodiment. The method comprises, in block 201, sending, by a first application stored in a device, an authorisation initialisation request to an authorisation server. The first application corresponds to the first application 109 stored in the device 100 of Figure 1. In other words, an application stored in a normal region of the device (i.e. REE) sends an authorisation initialisation request to a trusted authorisation server.

The authorisation server may require further authentication from the first application to prevent the authorisation service from being abused. The authentication may be done, for example, using passwords or cryptographic keys, and may involve end-user interactions on the device hosting the first application. The authorisation server may also impose further security policies such that the same device cannot send the authorisation initialisation request too frequently.

In block 203, the authorisation server generates a challenge value for transaction authorisation and transmits the challenge value to the first application, i.e. the application that sent the authorisation initialisation request. As previously discussed, the purpose of generating and sending the challenge value to the first application is to ensure that the attestation that is generated at a later stage is fresh and not an attestation previously used for a different authorisation request. Thus, the authorisation server my store the generated challenge value for a predetermined amount of time. For example, if the authorisation process is expected to complete within a second, then a policy may be specified such that the challenge values are only valid for 5 seconds.

In block 205, the method comprises sending, by the first application, the challenge value to a second application stored in the device, the second application comprising the API, wherein the second application comprises a counter. The second application corresponds to the second application 111 stored in the device 100 of Figure 1. In other words, the second application may be an application stored in a secure region of the device.

In block 207, the second application generates an attestation comprising the challenge value and transmits the attestation to the first application. The first application then transmits the attestation to the authorisation server in block 209.

The attestation may comprise at least one of an identifier associated with the API, the challenge value, an identifier associated with the first application, a counter value, and a device identifier. The second application may sign the attestation using an attestation key stored in the second application.

In block 211, the authorisation server validates the attestation. The validation may comprise validating a cryptographic signature using a public key included in the attestation. The authorisation server may further verify whether the challenge value in the attestation matches the challenge value generated and stored by the server and whether the challenge value has not expired, thereby confirming that the attestation has not been previously used. The authorisation server may also verify that the API identifier correctly refers to a protected API expected to be available in the specified device or device group, and that the identified first application is allowed to make such an invocation. If the counter has not been initialised such that its value starts at 0, the value thereof may also be used for validation; for example, if the protected API invocation is expected to be infrequent, a large counter value may indicate that the device may be under attack or has been compromised.

In block 213, the authorisation server generates a one-time API authorisation and transmits the authorisation to the first application to thereby enable the first application to invoke the API. The one-time API authorisation may comprise an identifier associated with the API, a device identifier, an identifier associated with the first application, a counter value and input data. In other words, when the validation (block 211) succeeds, the authorisation server may create an authorisation on the basis of the same data. The authorisation server may sign the one-time API authorisation using a private key of an asymmetric key pair, wherein a public key of the asymmetric key pair is known to the second application such that the second application may verify the signed authorisation. Using the method depicted in Figure 2, the authorisation server can be certain that the authorisation request comes from a valid device having a specified secure application (i.e. second application) and API. The use of a short-lived challenge ensures that the authorisation request is freshly made and has not been used before. The use of the secure counter ensures that the authorisation can be used once only.

As previously described in relation to Figure 1, additionally, input data can be used in the process of invoking the API. In block 205, the first application may additionally send input data for API invocation to the second application. The input data may comprise a hash value. In block 207, the second application may generate the attestation comprising the input data, in addition to the challenge value. In block 209, the first application may transmit the intended input data for the API invocation to the authorisation server. In block 211, the authorisation server may then validate the intended input data. The one-time API authorisation may comprise the input data.

Figure 3 schematically depicts a method for authorised API invocation, in accordance with an example embodiment. In particular, the method depicted in Figure 3 is a continuation of the method depicted in Figure 2, i.e. the steps depicted herein take place after the steps of Figure 2. In other words, after the one-time API authorisation has been received by the first application (through the method depicted in Figure 2), it can then be used for authorised API invocation. In block 301, the method may comprise sending, by the first application, the input data and the one-time API authorisation to the second application. In block 302, the second application may validate the one-time API authorisation and the input data and process the input data according to the API. In block 305, the second application may remove the received challenge value and increment the counter.

Figure 4 schematically depicts a method for secure in-field provisioning, in accordance with an example embodiment. The method may comprise, in block 401, sending, by the first application, a request for in-field provisioning to a provisioning server. The first application may be an application, stored in the normal region of the device, that is responsible for performing the in-field provisioning. The first application may be the same application that is responsible for performing factory provisioning. In block 403, the first application may receive, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning. The set of encrypted provisioning data may comprise a cryptographic key. That is, the first application may authenticate itself to the provisioning server and request in-field provisioning. The provisioning server may send a set of encrypted key materials and data to the device to perform in-field provisioning. The first application may use the steps of Figure 2 to obtain an authorisation to use the provisioning feature provided by the second application. The first application may then send data to be provisioned to the second application together with the authorisation depicted in Figure 3 to thereby complete the provisioning. As such, the factory provisioning API can be invoked in a secure way, such that each invocation will require explicit one-time authorisation from a trusted server, thereby protecting the API from abuse. Importantly, this process does not require the device to be physically present in a service centre.

According to an example, machine-readable instructions can be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and/or block(s) in the block diagrams.

Further, the teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure.

In some examples, some methods can be performed in a cloud-computing or networkbased environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

While various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable-storage media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

1. A method for application programming interface, API, invocation, the method comprising: sending, by a first application stored in a device, an authorisation initialisation request to an authorisation server; generating, by the authorisation server, a challenge value for transaction authorisation and transmitting the challenge value to the first application; sending, by the first application, the challenge value to a second application stored in the device, the second application comprising the API, wherein the second application comprises a counter; generating, by the second application, an attestation comprising the challenge value and transmitting the attestation to the first application; transmitting, by the first application, the attestation to the authorisation server; validating, by the authorisation server, the attestation; and generating, by the authorisation server, a one-time API authorisation and transmitting the authorisation to the first application to thereby enable the first application to invoke the API.

2. The method of claim 1, further comprising the steps of: sending, by the first application, input data for API invocation to the second application; generating, by the second application, the attestation comprising the input data and transmitting the attestation to the first application; transmitting, by the first application, the input data to the authorisation server; and validating, by the authorisation server, the input data, wherein the one-time API authorisation comprises the input data.

3. The method of claim 2, wherein the input data comprises a hash value.

4. The method of any preceding claim, wherein the authorisation server stores the generated challenge value for a predetermined amount of time.

5. The method of claim 4, wherein the step of validating the attestation comprises at least one of: validating a cryptographic signature using a public key included in the attestation, and verifying that the challenge value in the attestation matches the challenge value stored by the authorisation server.

6. The method of any preceding claim, wherein the attestation comprises at least one of an identifier associated with the API, the challenge value, an identifier associated with the first application, a counter value, and a device identifier.

7. The method of any preceding claim, wherein the second application stores an attestation key, wherein the attestation is signed by the attestation key.

8. The method according to any one of claims 2 to 7, wherein the one-time API authorisation comprises an identifier associated with the API, a device identifier, an identifier associated with the first application, a counter value and the input data.

9. The method of any preceding claim, wherein the one-time API authorisation is signed by the authorisation server using a private key of an asymmetric key pair, a public key of the asymmetric key pair known to the second application to thereby enable the second application to verify the signed authorisation.

10. The method of any preceding claim, wherein, in response to receiving the authorisation initialisation request from the first application, the authorisation server sends an authentication request to the first application.

11. The method of any one of claims 2 to 10, further comprising the steps of: sending, by the first application, the input data and the one-time API authorisation to the second application; validating, by the second application, the one-time API authorisation and the input data and processing the input data according to the API; and removing, by the second application, the received challenge value and incrementing the counter.

12. The method of claim 11, further comprising the steps of: sending, by the first application, a request for in-field provisioning to a provisioning server; receiving, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning.

13. The method of claim 12, wherein the set of encrypted provisioning data comprises a cryptographic key.

14. A device comprising: a processor; a memory coupled to the processor, the memory configured to store a first application and a second application, wherein the second application comprises an application programming interface, API, and a counter; the memory further configured to store program code executable by the processor, the program code comprising one or more instructions, whereby to cause the device to: send, by the first application, an authorisation initialisation request to an authorisation server; receive, by the first application, a challenge value for transaction authorisation from the authorisation server; transmit the challenge value from the first application to the second application; generate, by the second application, an attestation comprising the challenge value and transmit the attestation to the first application; transmit the attestation from the first application to the authorisation server; receive, by the first application, a one-time API authorisation from the authorisation server to thereby enable the first application to invoke the API.

15. The device of claim 14, wherein the program code further comprises one or more instructions whereby to cause the device to: send, by the first application, input data for API invocation to the second application; generate, by the second application, the attestation comprising the input data and transmit the attestation to the first application; transmit, by the first application, the input data to the authorisation server for validation, wherein the one-time API authorisation comprises the input data.

16. The device of claim 15, wherein the input data comprises a hash value.

17. The device of any one of claims 14 to 16, wherein the attestation comprises at least one of an identifier associated with the API, an identifier associated with the first application, a counter value, and a device identifier.

18. The device of any preceding claim, wherein the second application is arranged to store an attestation key, wherein the second application is further arranged to sign the attestation using the attestation key.

19. The device of any preceding claim, wherein the one-time API authorisation comprises an identifier associated with the API, a device identifier, an identifier associated with the first application, a counter value and the input data.

20. The device of any preceding claim, wherein the second application comprises a private key of an asymmetric key pair used by the authorisation server for signing the one-time API authorisation, wherein the second application is arranged to verify the signed authorisation.

21. The device of any one of claims 15 to 20, wherein the program code further comprises one or more instructions whereby to cause the device to: send, from the first application, the input data and the one-time API authorisation to the second application; validate, by the second application, the one-time API authorisation and the input data, and process the input data according to the API; and remove, by the second application, the received challenge value and increment the counter.

22. The device of claim 21, wherein the program code further comprises one or more instructions whereby to cause the device to: send, from the first application, a request for in-field provisioning to a provisioning server; receive, from the provisioning server, a set of encrypted provisioning data to thereby enable the device to perform in-field provisioning.