In the previous blog [1], I've focused on the trust distribution approach between Cloud and Fog Domains and how trustworthy networking is ensured through a divide-and-conquer strategy to create isolated trust domains in trust planes (CTFTP and FTTTP). To provide further insights on how the trust is managed between the components declared in the previous blog, this blog dives deeper into the trust management and underlying key management protocols required for three main certificate management procedures: creation, validation, and revocation.

Creating digital certificates in Fog Domain

While creating a self-signed certificate for the TNTA component is straightforward, since it represents the root CA in the system, issuing certificates for FTA components is much more complex. The main challenge for this procedure is the "offline" scenario: how FTA's certificate can be issued without TNTA's availability. To bridge the potential availability gap, upon its installation, FTA generates the public key pair that is valid in the local Fog Domain and generates the self-signed certificate if TNTA is unavailable. As FTA is the root CA within the Fog Domain, that is, local network, other Fog components will have to consider a self-signed certificate as the valid one since those components also cannot communicate with TNTA. Once TNTA becomes available, FTA revokes its self-signed certificate and sends the Certificate Signing Request (CSR) to TNTA to obtain the valid certificate for Cloud and other Fog Domains.

When FTA obtains its certificate, be it self-signed or TNTA-signed, it behaves as a Fog Domain's root CA. That allows FTA to issue other certificates in the local Fog Domain to other components, IoT devices, and users. Issuing certificates in Fog Domain is much more straightforward because it occurs in the isolated local network, often protected by firewalls and/or NATs, and without a high probability of FTA's unavailability, making certificate management simpler than in Cloud - Fog communication.  

Revoking certificates

Once the certificate is revoked due to its expiration or some malicious event that hinders the certificate's validity, it is critical to notify other entities in the trust domain about that. Two dominant approaches for that are Certificate Revocation List (CRL) [2] and Online Certificate Status Protocol (OCSP) [3]. CRL issues lists of the revoked certificates, which are then cached by trust domain entities. Compared to that, OCSP enforces a query-based approach hosted by the CAs and allows other entities to ask if the given certificate is revoked during the certificate validation procedure.

As with certificate creation, the "offline" Fog Computing requirement plays a determining role in choosing between CRL and OCSP. Namely, OCSP is impossible to apply when TNTA is unavailable. That is why CRL must be used in Cloud to Fog communication. However, OCSP offloads significant computational and storage load from resource-constrained sensors to more powerful Fog Nodes. For that reason, it makes sense to apply OCSP for the certificates issued by FTA or other Fog Domain components.

Digital certificates validation

Certificate validation is based on checking digital signatures in the trust chain up to the root CA's (TNTA) certificate. To achieve that, TNTA's certificate has to be securely delivered to all entities in the system. For that reason, all Fog components obtain TNTA's certificate as part of the installation image, which is an offline shared secret. Through that, all Fog components can validate all digital signatures up to TNTA's certificate since it is available to them also when the connection to Cloud is broken.

[1] https://www.netidee.at/trustworthy-context-aware-access-control-iot-env…

[2] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard). Fremont, CA, USA: RFC Editor, May 2008. url: https://www.rfc-editor.org/rfc/rfc5280.txt 

[3] S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 6960 (Proposed Standard). RFC. Fremont, CA, USA: RFC Editor, June 2013. url: https://www.rfc-editor.org/rfc/rfc6960.txt