RESEKRA System for Remote Attestation

RESEKRA System for Remote Attestation: History

Please note this is an old version of this entry, which may differ significantly from the current revision.

Contributor: Ernesto Gómez-Marín , Luis Parrilla , Gianfranco Mauro , Antonio Escobar-Molero , Diego P. Morales , Encarnación Castillo , Ernesto Gomez Marin

Edge computing can be considered as a framework where multiple unsupervised devices communicate with each other with lack of hierarchy, requesting and offering services without a central server to orchestrate them. Because of these characteristics, there are many security threats, and detecting attacks is essential. Many remote attestation systems have been developed to alleviate this problem, but none of them can satisfy the requirements of edge computing: accepting dynamic enrollment and removal of devices to the system, respecting the interrupted activity of devices, and last but not least, providing a decentralized architecture for not trusting in just one Verifier. This security flaw has a negative impact on the development and implementation of edge computing-based technologies because of the impossibility of secure implementation.

remote attestation
edge computing
Internet of Things
embedded systems
Trusted Platform Module

1. Introduction

The number of things connected to the internet (Internet of Things, IoT) is growing exponentially, from 6.1 billion in 2018 to 14.7 billion in 2023 ^[1]. This growth is continuous, and there is no evidence that it will stop.

The current IoT structure relies on cloud computing. An IoT device collects information from the environment (sensor), sends it to a distant centralized server, which processes it along with currently stored information and information from other sensors, and generates, whether required, an action response. The response is then sent to a new IoT device, namely an actuator, which performs the appropriate action often in the nearby of the sensor. This is a simple and secure system from the service provider’s point of view, but due to the remoteness of the server from the nodes, it generates a high volume of data traffic and a high latency not suitable for real-time IoT applications. Moreover, it is not scalable enough with the current growth of IoT devices because of the large network use and the burden on cloud servers ^[2]^[3].

In this context, it is convenient for data to be processed at the edge for shorter response times, more efficient processing, and less pressure on the network. The technologies that enable computation at the edge of the network, on the data flow between the cloud services and the IoT services are known as edge computing ^[2]. In this scenario, the devices at the edge of the network that provide services (processing and/or data storage) are called edge nodes, while user devices are those that require real-time interaction or high storage capabilities. In this paradigm, user devices will act as edge nodes whenever possible, offloading their computing task to adjacent nodes if too burdensome at a given time ^[3].

On the other hand, the inherent distributed structure of edge computation implies additional security challenges over cloud computing. Egde computing has to protect different layer of technologies (from cloud to IoT devices) as in cloud computing, but it also needs to provide a distributed global connectivity of heterogeneous devices between the different layers. Rodrigo Roman et al. ^[4] define it as a combination of “the worst-of-all-worlds”. The scenario becomes more complicated when the researchers consider that user devices continuously enter and leave the local network, that means, close mobile users (mobile subscribers), e.g., mobile phones or cars, which is called Mobile Edge Computing (MEC) ^[5].

2. RESEKRA Description

As will be detailed in this section, the main contributions of RESEKRA can be summarized as follows:

The use of Sealed Keys that can be used by the proprietary (the Attestor) temporarily and only when the current device status is approved by the Verifier, thus proving correct Attestor status only by proving ownership of the Sealed Key.
The same Sealed Key can be used with different device status (always approved before-hand by the Verifier), allowing software updates without continuous revocations and avoiding a complex PKI.
The creation of the Sealed Key can be realized completely remotely in a untrusted Attestor, allowing great flexibility and a plug-and-play business model perfect for Edge computing.

Figure 1 shows the general scheme of the remote enrollment process in RESEKRA. In the next subsections, the roles and operations performed in each of the steps will be detailed.

/media/item_content/202207/62d8b15ecdedesensors-22-05060-g001.png

Figure 1. Remote enrollment process. The scheme represents all the enrollment process from the device manufacturer to the supervised creation of the sealed key.

2.1. Roles

The main elements included in RESEKRA are the following:

Attestor: edge devices with the hardware RoT, i.e., TPM and CRTM.
Hardware Provider: the entity in charge of manufacturing the Attestor and providing the firmware and RoT. It is considered a trusted entity.
Software Provider: the entity in charge of designing the Attestor software and creating the RML. It is a trusted entity.
Programmer: the entity in charge of programming the Attestor. It is a not trusted entity.
Deployer: the entity responsible for physically deploying the device and providing an authentication method. This entity is semitrusted, because it does not need a high level of knowledge to securely deploy the device, since there is no offline enrollment process and it has no interest in hacking the system because it is one of the stakeholders interested in providing the service. On the other hand, it would require a high level of expertise to manipulate physically the root of trust and go unnoticed by the rest of stakeholders.
Verifier: the entity in charge of verifying the root of trusts of the Attestor, creating the SeK, verifying the Attestor status and authorizing the use of the SeK in the TPM.
TPM: Hardware security module following the TPM 2.0 specifications.
Edge computing user: the entity that requires communication with the Attestor to receive data (sensor) or to analyze/store data (Edge node).

In this entry, the researchers do not focus on authentication. They consider that the Deployer is responsible for providing an authentication method for the Attestor, edge computing user and Verifier.

2.2. Certification of Manufacturer

In this first phase, the Attestor manufacturer and programmer shall create the needed certificates.

2.2.1. Hardware Provider

When the Attestor is fabricated, the Device Manufacturer stores the necessary certificates (Manufacturer Certificates) in the device to identify the existence of the necessary root of trust (TPM and CRTM) on the Attestor. This certificate is signed by the Hardware Provider and linked to the EK. The Verifier can trust several Device Manufacturers.

2.2.2. Software Provider

The software provider installs all the needed software in the Attestor and generates a list of measurements that will be used as reference, the Reference Measurements List (RML). This list is then signed by the software provider. The RML has to be provided to the Verifier and updated in case of software update. The software provider can be any stakeholder, e.g., Hardware provider, deployer or end user.

2.3. Remote Enrollment

At this moment in the process, the device can be deployed by the owner in any considered location. Because the rest of RESEKRA will work remotely, the deployment can be realized by inexperienced staff. Once the device is deployed, the Verifier has to assert the device’s hardware Root of Trust and to manage the creation and the validation of some special keys in the Attestor. It is a completely remote process and can be realized even in a untrusted Attestor. Therefore, the Verifier’s role can be dynamically changed, and even multiple Verifiers can work at the same time, sharing trust and responsibility.

2.3.1. Edge Device Validation

Once the IoT device has been deployed, the Host_TPM requests the TPM for the public Endorsement Key (EK_PuK) and orders the creation of the Attestation Key (AK). It sends the public information of Attestation Key (AK_Pubdata) and the public Endorsement Key (EK_PuK) to the Verifier. The Verifier checks that the Endorsement Key belongs to a genuine TPM from a trusted manufactured edge device. The check is done through the Attestor’s Manufacturer Certificates. Then, it verifies the attributes of AK (the Restricted attribute, among others).

2.3.2. Sealed Key Creation

The Verifier knows that the EK_PuK belongs to a trusted manufactured edge device but has not yet asserted that the Attestor is the owner of this EK. Then, the Verifier creates the asymmetric key pair, Authorizer, and encrypts the public key (Aut_PuK) with symmetric encryption using “Secret” as the symmetric key.

Next, it encrypts “Secret” using Makecredential and using EK_PuK and AK_Pubdata as input to create Credential. If the Host-TPM shows knowledge of Aut_PuK, it proves to own the TPM, EK, and AK with the asserted attributes. Finally, the Verifier sends Credential and Aut_PuK encrypted to Host-TPM. If Host-TPM shows knowledge of Aut_PuK, it proves the ownership of EK.

When Credential reaches Host-TPM, it decrypts the Credential with Activatecredential obtaining “Secret” and uses it to decrypt Aut_PuK. Now, because it has Aut_PuK, it can instruct TPM to create a sealed key (SeK) with the “tpm2_policyauthorize” using Aut_PuK as the authorizing key. The output of running the sealed key creation script is shown in Figure 2.

/media/item_content/202207/62d8b1833302dsensors-22-05060-g002.png

Figure 2. Output of the script for sealed key creation.

2.3.3. Sealed Key Validation

The TPM generates an attestation certificate for SeK (Cert_SeK). This certificate is asserting that the object with the name SeK_name is stored in the TPM; hence, the TPM is bearing it. Then, the TPM signs it with the AK and sends it to the Verifier together with SeK_Pubdata.

The Verifier has to validate this information once received. First, the Verifier checks that the certificate starts with TPM_GENERATED and is signed with the suspected AK. This means that the TPM has generated the certificate if AK is a real AK, which will be verified in the next step. Finally, the Verifier needs to assert that this is the correct type of certificate.

It starts with TPM_GENERATED;
It is signed by AK;
It is an attest certificate.

This validation means that Cert_SeK is genuine. Now, the Verifier will recompute the SeK_name locally from SeK_Pubdata. It shall match with the name backed by the Cert_SeKcheck, and finally, the Verifier will verify all the features of SeK:

The sealed key is the same being attested by the certificate;
The policy used to create the sealed key is correct (tpm2_policyauthorize using Aut_Pub). This point is essential, because it proves knowledge of the Aut_Pub;
Verifying the attributes of the SeK.

If all verifications are successful, the Verifier has been able to create completely remotely, without the need for pre-shared secret, a sealed key in the Host-TPM’s TPM. The Verifier would have complete control over this sealed key. The Attestor will be able to use this key only when satisfying the signed requirements imposed by the Verifier.

2.4. Attestation

At this point, the CRTM measures the BIOS and the IMA measures the integrity of all files executed. This is a runtime measurement, so when any new or modified file is executed, it is measured, and the result is stored in the measurement list and extended to the PCR.

The Attestor initiates the remote attestation by sending a request to the Verifier, and the last one replies by sending back a random nonce to the Attestor. The TPM generates a Quote signed by the AK, which includes the nonce to avoid replay attacks. The Quote is a certificate including several important parameters; those most relevant for RESEKRA are:

TPM_GENERATED, to confirm the veracity when signed by the AK;
The random nonce, to avoid replay attacks;
Reset value of TPM. Value that changes when Host-TPM is rebooted;
Value of PCR.

The Attestor sends the Quote together with the measurement list to the Verifier. It asserts the veracity of the certificate (TPM_GENERATED, signature, and random nonce) and uses the measurement list to rebuild the PCR value found in Quote. If the reconstruction is correct, it means that the measurement list was not adulterated.

Finally, the Verifier compares the measurement list with the Reference Measurement List (RML). The Verifier may have obtained this RML through the Host-TPM signed by the trusted Device Manufacturer or from the cloud. Now, the Verifier can check program by program if there is a difference and where.

When the list is approved by the Verifier, the Verifier can create an authorization to use the SeK for the particular values of RESET and PCR specified in Quote, and it sends the authorization signed by AuTK to the Host-TPM. Figure 3 shows the particular code to generate and sign the combined policy. The complete codes are accessible at: ^[6].

Figure 3. Section of the Verifier code where it computes the policies for using the SeK and signs it if and only if the Attestor passed through the attestation process.

Once the authorization is received, the Host-TPM sends it to the TPM to unlock the SeK. The TPM verifies the signature and checks that it meets the requirements of the authorization (RESET and PCR values), being able to use the SeK until these requirements change, i.e., until it reboots or until a new or modified program is used. If the PCR value changes, the Attestor will request a new authorization from the Verifier; however, if a program that was not supposed to be executed is run, the Attestor will not obtain a new authorization until it is restarted and ask for a new one. A device will not be able to reuse an old authorization because those are sealed to the RESET value of the TPM, which prevents the use of authorizations for old decommissioned software.

2.5. Daily Life Functionality

Whenever the egde device proves ownership of the SeK, the TPM will first verify the signature of the policy provided by the server, secondly, it will assert the signed polices (values of PCR and Reset), and finally, it will grant access to sign with the SeK, proving the correctness of the software, and therefore, no additional attestation is needed. Figure 4 shows the script using the SeK to sign the measure of a pressure sensor satisfying the policy that was set when the SeK was generated (authorization policy in Figure 2).

/media/item_content/202207/62d8b1a651c62sensors-22-05060-g004.png

Figure 4. Output of the script using the sealed key to sign a measured value after satisfying the policies.

This key can also be used to prove authentication. In protocols such as the well-known cryptography protocol Transport Layer Security (TLS) ^[7], or signing transactions for blockchain, asymmetric keys are used for the authentication, thus; the Sealed key pair can be use to prove correctness at the same time that authentication. The end user can trust in the SeK because it is coming with a certificate from a trusted third party, which is commonly the Verifier itself.

2.6. Implementation

For implementing the system, the researchers employ a low-price System on Chip (SoC), Raspberry Pi 4B: Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz 8 GB LPDDR4-3200 SDRAM and a pressure sensor DPS310 Pressure Shield2Go ^[8]. Additionally, they have used a TPM IRIDIUM9670 TPM2.0 LINUX ^[9], a hardware security module by Infineon Technologies GMBH specifically designed for Raspberry Pi SoCs. In Figure 5 is shown the setup. The researchers' implementation lacks CTRM, but it is a feasible solution for the real-world market ^[10].

Figure 5. Experimental setup. Raspberry Pi 4 with TPM (green hardware) and pressure sensor (red hardware).

The software has been developed over WenXin’s code, which is available in a public repository ^[11]. This software presents a classic remote attestation with Attestor and Verifier. The researchers have used this repository as a baseline for the implementation of their presented novelties, and the result can be found in ^[12] for the Attestor and ^[6] for the Verifier.

3. RESEKRA Use Cases

There are several ways to use RESEKRA, depending on whether the edge device programmer is the same as the manufacturer, regarding how the Verifier obtains the RML, how it obtains the trust on the sealed key, or who takes the role of the Verifier. In the process, the researchers consider that there is a trusted system to provide the identity of the ED devices to the end user. Two use cases were considered for RESEKRA: edge computing as a trusted service and edge computing as a trusted service—No TTP online.

In the case of edge computing as a trusted service, the researchers have the case of a company that offers edge computing for a fee. This company is responsible for the deployment and maintenance of edge nodes. Additionally, in this use case, the researchers can find the manufacturers of the edge devices, which are trusted by all. The Verifiers, in this case, are a cloud service with high latency and some downtime. Finally, the researchers find the end users who rely on the Verifiers to use the reliable edge device services requiring very low latency.

The second use-case, edge computing as a trusted service—No TTP online, is similar but with a fundamental difference: there are no cloud services offering the Verifier service.

There are other possible use cases where the Reference Measurement List is trusted through a voting method or is provided along with the edge device software from a public repository such as ^[13]. Edge devices that have already been validated can also be used as a Verifier.

3.1. Edge Computing as Trusted Service

In edge computing as a trusted service, the researchers have (1) the trusted entity in charge of designing, programming, and manufacturing the edge devices for edge computing (Trusted Designers); (2) several semi-trusted investors in charge of deploying and maintaining the edge devices (Semitrusted Maintainers); (3) Trusted Clouds and (4) mobile end users, e.g., a car.

3.1.1. Roles

The Trusted Designers are responsible for designing an edge device with CRTM and TPM. They are also responsible for designing the secure software. Finally, they manufacture the product and store all necessary certificates on the edge device.

Semitrusted Maintainers are entities with little technical knowledge. They are semi-trusted because they have no interest in making attacks into the system, but they have no knowledge of how to prevent them. They have the capacity and interest to deploy and maintain an edge device in a specific area, such as a non-profit interested organization, e.g., a government, or an interested profit organization with a business model based on subscriptions or blockchain using utility tokens, e.g., Helium ^[14].

The Semitrusted Cloud (SC) is responsible for verifying and signing the authorizations for the SeKs of edge devices. Every end user has a set of trusted SC. The SC is semitrusted because the end user only trusts some of them.

The last role is the end user, who needs to trust edge devices to use edge computing services.

3.1.2. Process

First, Semitrusted Maintainers purchase an Edge-Device N (

E D_{N}

)

\forall N \in N

from Trusted Designers and deploy it wherever they see a fit. Thanks to the remote and versatile key creation system in RESEKRA, there can be several independent SCs verifying the integrity and authenticity of the received documents. These SCs can belong to third parties. The

E D_{N}

communicates with a set

O_{N}

of SCs, sends them the reference measurement list and the manufacturing certificates signed by the Trusted Designers. A subset

P_{N}

O_{N}

approves the Remote Enrollment and issues a certificate with the SeK generated and

E D_{N}

’s identifier. The identifier has to be an universally unique identifier ^[15] to avoid Wormhole attacks ^[16]. In the scenario, the researchers propose using the last 128 bits of the hash of the EK_PuB as an identifier.

A subset

Q_{N}

P_{N}

approves the attestation and grants the authorization to use the SeKs, as long as the device is not rebooted or its software is not modified. Additionally, a time limit can be added to this authorization.

At this moment, the

E D_{N}

can act as a Verifier for the nearest IoT devices by using a software-based remote attestation such as SoftWare-based ATTestation (SWATT) ^[17], where the time response is essential, and therefore, a one-hop network is a fundamental requirement.

Finally, end users, by requesting the services of

E D_{N}

, have to provide a priority organized set G of SCs and a Random Nonce (RN). If any of the elements of G belong to

Q_{N}

, the

E D_{N}

will sign the RN using the SeK approved by the most priority SC belonging to G and

Q_{N}

, and it will furnish the corresponding certificate. Since the identity in the certificate is based on the EK_PuK, the identity provider just has to provide one identifier for

E D_{N}

, and it is valid for all the

E D_{N}

’s SeKs. Otherwise, the

E D_{N}

is considered untrusted by the end user.

When

E D_{N}

is trusted, the end user requests the edge computing services (gathering data or processing data) and measures the required time of the service. At the end of the service, the

E D_{N}

signs the hash of the RN with the results of the service using the SeK. If the final signature never arrives or takes longer than expected, the end user does not trust the results and reports the irregularity.

However, it needs to check the correctness of the edge devices before using their services. The car only has the name of the edge devices and a set of cloud services that are trusted for this car but are not accessible in real time.

Figure 6 shows an scenario where a car enters in a location with an edge computing network, and it needs edge services from 3 EDs such as gathering data from sensors or using computer processing. However, it needs to check the correctness of the edge devices before using their services. The car only has the identifier of the edge devices and a set of SCs G that are not accessible in real time.

Figure 6. Visualization of edge computing as trusted service. A car reaching a location needs the local services of several edge and IoT devices. All these devices have many SeKs available validated by an SC each. The car just trusts in some of the SCs, those which belong to subset G.

Firstly, the car requests a signed RN from the three EDs, each one with three different subsets Q, but only

E D_{1}

and

E D_{3}

have passed through a remote attestation of at least one of the SCs belonging to G. Then, by simply signing the RN with their SeKs,

E D_{1}

and

E D_{3}

prove their correctness, and the car puts the trust in them and starts using their services.

3.2. Edge Computing as Service—No TTP Online

In edge computing as service—No TTP online, the researchers consider the need of avoiding the use of a Semitrusted Cloud. Perhaps, because the internet connection is not available, there are not SCs of G belonging to Q or simply to avoid the use of a TTP.

In this field, the researchers have the same roles as in the previous case, except for the absence of SC.

Processes

When the end user wants to use the services of the edge device, and there is not any trusted third party available to act as a Verifier, the end user himself can act as a Verifier.

Throughout the communication process, a constant status of the software is ensured by continuously proving the SeK ownership. The process of document verification and SeK creation should be created beforehand to avoid delaying the start of the edge computing service. Figure 7 represents the differences between the two use-cases presented in this section. On the right of the image, all the phases (in purple) are processed between car and edge device, and there is no need of third party acting as a Verifier.

Figure 7. Visualization of the two use cases, edge computing as service (in blue) and edge computing as service—No TTP online (in purple).

This entry is adapted from the peer-reviewed paper 10.3390/s22135060

References

Cisco, U. Cisco Annual Internet Report (2018–2023) White Paper; Cisco: San Jose, CA, USA, 2020.
Shi, W.; Cao, J.; Zhang, Q.; Li, Y.; Xu, L. Edge Computing: Vision and Challenges. IEEE Internet Things J. 2016, 3, 637–646.
Liu, D.; Yan, Z.; Ding, W.; Atiquzzaman, M. A survey on secure data analytics in edge computing. IEEE Internet Things J. 2019, 6, 4946–4967.
Roman, R.; Lopez, J.; Mambo, M. Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges. Future Gener. Comput. Syst. 2018, 78, 680–698.
ISG; ETSI; GMI; Mobile Edge Computing; Market Acceleration; MEC Metrics Best Practice and Guidelines. Available online: https://www.etsi.org/deliver/etsi_gs/MEC-IEG/001_099/006/01.01.01_60/gs_MEC-IEG006v010101p.pdf (accessed on 23 May 2022).
Ernesto. RESEKRA: Verifier. Available online: https://github.com/ernesto418/Remote_attestation_server/ (accessed on 21 June 2022).
Dierks, T.; Rescorla, E. The Transport Layer Security (TLS) Protocol Version 1.2. RFC5246. 2008. Available online: https://www.rfc-editor.org/info/rfc5246 (accessed on 20 May 2022).
Technologies, I. DPS310 Pressure Shield2Go. Available online: https://www.infineon.com/cms/en/product/evaluation-boards/s2go-pressure-dps310/ (accessed on 21 June 2022).
Technologies, I. IRIDIUM9670 TPM2.0 LINUX. Available online: https://www.infineon.com/cms/en/product/evaluation-boards/iridium9670-tpm2.0-linux/ (accessed on 23 May 2022).
Mode, M. Secured Boot for ARM Processor Platforms. Available online: https://www.infineon.com/dgdl/Infineon-ISPN-Use-Case-Secured-boot-for-ARM-processor-platforms-ABR-v01_00-EN.pdf?fileId=5546d4625bd71aa0015c0b1fceee0851 (accessed on 20 May 2022).
Leong, W.; Yushev, A. OPTIGA™ TPM Application Note Remote Attestation. Available online: https://github.com/Infineon/remote-attestation-optiga-tpm (accessed on 23 May 2022).
Ernesto. RESEKRA: Attestor. Available online: https://github.com/ernesto418/Remote_attestation_TPM/ (accessed on 21 June 2022).
Linux Kernel. Available online: https://github.com/torvalds/linux (accessed on 20 May 2022).
Helium©, People-Powered Network, 2021 Helium Systems Inc. Available online: https://www.helium.com/ (accessed on 28 January 2022).
Leach, P.; Mealling, M.; Salz, R. A Universally Unique Identifier (uuid) urn Namespace. RFC 4122. 2005. Available online: https://www.rfc-editor.org/rfc/rfc4122 (accessed on 24 June 2022).
Hu, Y.C.; Perrig, A.; Johnson, D.B. Wormhole attacks in wireless networks. IEEE J. Sel. Areas Commun. 2006, 24, 370–380.
Seshadri, A.; Perrig, A.; Van Doorn, L.; Khosla, P. SWATT: Software-based attestation for embedded devices. In Proceedings of the IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 12 May 2004; pp. 272–282.

© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.