DATA SECURITY
Security in the world of AI, IoT and Edge Computing- Part 2
5 min introduction to common security concerns in software systems
In the last article we looked at security risks and their solutions when data is stored on the machine and transferred over the wire. We also looked at solutions around establishing a trusted communication between edge server and cloud server using on-boarding technique and HTTPS. Please read the first article here and that will help you in understanding the full context.
Onboarding techniques and HTTPS are not sufficient when establishing a Zero Trust communication between edge server and cloud server.
Let’s take a use case from the IoT and edge virtualization world to understand the problem in detail.
Edge devices from an oil rig are sending data to the cloud but they are not directly connected to the cloud, they are connected to a proxy in between and proxy is communicating with the cloud.
This case is similar to the use case we talked about in the first article.(Devices are referred to as on-premise servers in the first article). The only change is, in this use case devices are talking through a proxy instead of talking directly with the cloud. Devices think that they are talking with the cloud but in reality they are talking with a proxy.
Risk: What if the proxy gets compromised and hacker does a man in the middle attack ? Rogue proxy will send malicious data to the cloud, how should the cloud verify the integrity and authenticity of the data ? How should it verify that no one in between has altered the data ?
Solution: As we discussed in the previous article, the device and cloud will first establish a secure TLS connection and then the device will start a handshake process(on-boarding) and submit its identity to the cloud server. Cloud server will verify the device and if the handshake is successful then the device can start communicating with the cloud server. But the problem in this case is data on the cloud server is not directly coming from the device, it is coming via the proxy. So we need to make sure that the proxy does not alter the data.
You can use digital signatures to solve this problem. Devices can sign the data using the private key of its signing certificate before sending and it should send the signature along with the data to the cloud. Cloud can verify the signature using the device public key of the signing certificate (Public part of the device signing certificate needs to be shared with the cloud).If someone alters the data in between then the signature verification will fail on the cloud and it will know that someone in between is trying to alter the data. Cloud can raise an alarm or block the device until further action is taken by the manager of the device.
Additional security on top of HTTPS:
Let’s take a look at one more security consideration where we want to add additional security on top of HTTPS. When data is flowing between edge device and cloud they are secured using HTTPS but there are cases where because of regulatory requirements by government you may be asked to divert the data through a firewall, so that regulatory body of government can verify the data.
Let’s take the above use cases where the devices running in an oil rig or inside a hospital’s premise is communicating with the cloud server and understand how we can add additional security on top of HTTPS.
The devices in the above cases will poll config from the cloud server and these configs can have very sensitive data in it such as AWS S3 credentials for downloading docker images or wi-fi credentials. Although the communication between the device and cloud is happening on a secured channel over HTTPS and all the data is encrypted, still we want to add an additional layer of security for credentials present in the config.
How can we do it ? How can we add additional encryption for the sensitive data ? What kind of encryption technique should we use ?
We can use both symmetric key and asymmetric key based encryption to encrypt the sensitive data. But there are security considerations which we should assess before deciding the type of encryption.
Symmetric key encryption is a type of encryption that makes use of a single key for both the encryption and decryption process.
Asymmetric key encryption, on the other hand, makes use of two keys. A private key and a public key. The public key is used for encrypting, while the private key is used for decrypting.
If you use a symmetric key based encryption technique(e.g. AES) on the cloud, then you need to share the key with the on-premise device for decryption. This holds potential security concerns, what if the key gets compromised ?
We will use ECDH and look at very high level how we can use it to add additional security to the sensitive data.
ECDH is also a symmetric key based algorithm but you don’t need to share the keys used for encryption on the cloud with the device for decryption.
For encryption and decryption using ECDH we need two sets of public and private certificates. One set of public and private cert will be for the cloud and another set of the certificate will be for the device. Public certificate of cloud will be sent to the device and public certificate of device will be sent to the cloud.
For encryption on cloud first we need to generate a symmetric key using the private cert of the cloud, public cert of device and a random nonce. This generated symmetric key will be used to encrypt the data.
Now the sensitive data in the config will be encrypted and sent along with the config to the device, cloud will also send the nonce it used for encryption to the device. Now the device has to decrypt the data for that it needs a symmetric key. But as we discussed the encryption/decryption keys are not shared for the ECDH algorithm. Device will generate a symmetric key using the private cert of the device, public cert of the cloud and the random nonce sent by the cloud. Symmetric key generated by the device will be the same as the cloud and the device will use it to decrypt the data.
Summary:
Zero Trust security can be achieved using on-boarding process, HTTPS and signature verification.
Addition security on top of HTTPS can be achieved using ECDH based encryption and decryption.