I've worked in tech for years but never fully grasped how secure connections form.
The term "security" used to unsettle me.
Recently, I learned about FoundriesFactory's secure connections. I'll share the basics in my blog without delving into the technicalities of encryption and keys. It's about how we link our client devices at FoundriesFactory.
I'll soon post a more technical piece on encryption and PKI.
First, let's address why secure device-to-cloud connections matter. Simply put, unsecured devices are vulnerable, and internet connectivity increases this risk.
Basic Principle
Symmetric encryption uses a single key for both encryption and decryption. The key turns plaintext (readable data) into ciphertext (encrypted data), which appears scrambled or unrecognizable to those without the key. The same key used to encrypt the data is used to decrypt it, restoring it to its original form.
This method is used when you don't want anyone else to have access to these files.
If Paul encrypts a file and sends it to Bob, he must also provide Bob with the key. The process of sending this key securely is a significant challenge because if an unauthorized party intercepts the key during transmission, they can decrypt and access the information.
Sharing the key raises the possibility that this key and file could leak and a third person could access it.
Asymmetric encryption was developed to address this issue, offering a secure means of exchanging data without the need to share a private key
Asymmetric Encryption
Asymmetric encryption uses a pair of keys: a public key, which can be shared with anyone, and a private key, which is kept secret. Anyone can encrypt data using the public key, but only the holder of the paired private key can decrypt it.
The concept of public and private keys starts here, that is, one key you keep super safe, and the other you share with the world.
Imagine Paul is sending a secret letter to Bob in a language only they understand (that's like encryption). But before Paul starts writing, he asks Bob for a special secret decoder (this is Bob’s public key). Bob happily mails it to Paul, who then writes his letter using the decoder, making the letter look like gibberish to anyone who might sneak a peek (this is encryption with the public key).
Paul sends his now scrambled letter back to Bob, who uses his own secret decoder ring (his private key) that only he has, to read Paul's letter (this is decryption with the private key).
Now, this is pretty similar to what happens when you visit a website with HTTPS:
- The website gives your browser a special decoder for their language (the server’s digital certificate with a public key).
- Your browser checks this decoder with some trustworthy friends (certificate authorities) to make sure it's legit.
- Once the browser gives a thumbs up, it uses this special decoder to chat securely with the website.
But there’s a sneaky twist in our tale! What if a villain pretends to be Bob and sends Paul a fake decoder? Then Paul might end up sending his secrets to the villain instead (this is like a Man-in-the-Middle attack).
To avoid this, there's a group of super helpers (the Certificate Authorities) that vouch for the real Bob. They tell Paul, "Yep, we've checked, this decoder is definitely Bob’s!" That way, Paul can be sure he's sending his letter safely to Bob.
And for an extra layer of security, when your browser talks to a website using HTTPS, it does a special secret handshake called TLS (Transport Layer Security). This handshake makes sure the conversation stays between just your browser and the website, like whispering in a noisy room.
So, in short, this whole process makes sure that when you're telling a website your secrets (like passwords or credit card numbers), no one else can listen in or pretend to be the website you trust.
Digital Certificates
Digital certificates are used to guarantee the identity of a computer, server, webpage, and so on. They are similar to personal identity documents, where more information is put together to define who you are. As with personal documents, a digital certificate is verified by a third party, called a Certificate Authority (CA).
But what information does a digital certificate carry?
The main information found in a digital certificate is Public Key, Subject Name, Issuer Name, Validity period, among others.
In order to simplify, imagine that now, instead of Bob sending his public key to Paul, Bob sends his certificate which has been signed by a third party.
Bob's digital certificate contains Bob's public key, name, and who issued this document.
That being said, Paul uses the public key of the Certificate Authority (CA) to verify the certificate and be sure of Bob's identity.
Finally, to guarantee the Certificate Authority's public key is valid, the main software companies such as Google, Microsoft, and many others ship the CA certificates with browsers and other software.
Public Key Infrastructure (PKI)
All this talk of secret codes, digital guardians, and private chats is part of what's called Public Key Infrastructure (PKI). So, when you pop over to a website and spot a padlock next to the URL, it means that this whole PKI process has been successfully done to keep your visit secure.
Let's break it down using Paul's new online store as an example:
- First off, Paul sets up a digital lock and key system for his store (he creates a public and private key).
- He then sends a digital ID, with his digital lock (public key) to a digital notary (the Certificate Authority or CA).
- This digital notary checks Paul's details and seals his application with a shiny digital stamp (this is the digital certificate for Paul’s public key).
- Now, whenever a shopper pops into Paul's online store, their web browser automatically picks up the certificate, like getting a secret VIP pass.
- The shopper's browser is like a little detective; it examines the VIP pass to make sure it's the real deal. If everything looks good, it starts a super-secret convo with Paul's store.
So, every customer who drops by can shop with peace of mind, knowing that their chats and transactions with Paul are in their own secret code, invisible to anyone else browsing the aisles.
Does it work for IoT and Edge Devices?
When we think about how secure connections work in the world of IoT, it's a bit different from our online store scenario. Here's why:
Imagine devices like weather sensors or smart home gadgets that need to chat with a server, sending info like temperature or whether your porch light is on. These devices aren't like regular computers—they don't have browsers or someone typing in commands.
So, how do they ensure they can talk securely with the server?
IoT and Edge Devices are like secret agents in the field, each with their own special gadgets (keys and certificates) and missions (sending data like temperature readings). But here's where it gets interesting:
- They don't come with a handy guide to who's a friend or foe (trusted CAs), and they can't always call headquarters (the internet) for a background check.
- Some of these gadgets have limited storage, so they can't carry a big book of trusted friends (CA public keys).
- Plus, they might be off the grid, working in remote areas without a signal, so they can't always ask if someone's identity checks out (online verification).
- And they usually only talk to their own base (the IoT server), not just any passerby on the internet (like customers visiting an online store).
Imagine a team of spies, each with a high-tech gadget that needs a secret password or a special key to operate. Now, suppose all these gadgets had the same password or key.
Super convenient, right? But what if a baddie gets their mitts on this one-size-fits-all secret? They'd have a golden ticket to act like any gadget in the arsenal—a security nightmare!
That's the sticky situation for some companies when they look for shortcuts with their smart devices:
- Universal Token Authentication: Imagine if every gadget had a built-in secret nod or wink to say, "I'm one of the good ones." It works fine until a sneaky spy spots this nod or wink. Suddenly, they're a wolf in sheep's clothing, and all your gadgets are at risk.
- All Keys Everywhere: It's like each gadget comes with a VIP all-access pass—a duplicate set of keys (public, private keys, and certificates) to the secret club. If just one of these passes falls into the wrong hands, it's an open invitation to every secret corner of your operation.
What is the best solution then?
The ideal for IoT and Edge devices is to create your own PKI (Public Key Infrastructure).
Usually, when we visit a website, we're like shoppers entering a store, with security guards (Certificate Authorities like DigiCert, Let's Encrypt, etc.) checking IDs at the door.
But for IoT and Edge devices, it's more like each device is a unique boutique in a large mall, and your company owns the mall and employs its own security team (your own Private Certificate Authority) to check IDs and grant access to the boutiques.
In the context of Foundries.io's services:
- Your own Private Certificate Authority (CA): This is the "security team" in the analogy. Your private CA acts as the trusted issuer of digital certificates within your IoT ecosystem.
- Root of Trust: This is the most foundational level of your security infrastructure, akin to the head of security in a mall, whose trust is never in question.
- Server TLS Certificate: The certificates that are presented by the device gateway (akin to security badges or IDs) to establish a secure connection with devices.
- "online-ca" and "local-ca": These are like the ability to issue temporary passes or special access credentials for different parts of the mall (your IoT network) as needed, either by connecting to Foundries.io ("online-ca") or independently ("local-ca").
- The "mall" is your IoT ecosystem, and within this ecosystem, you have full control over the security measures in place, as opposed to a more public scenario (like visiting a regular website) where security is managed by well-known, external Certificate Authorities.
Certificate Authority - Chain of Trust
A Certificate Authority can give the right to issue certificates to other subordinate Certificate Authorities.
That way, if something happens to a subordinate Certificate Authority, it is possible to revoke its authorization and minimize the damage.
You might be asking how it can help you to design an electronic device.
Imagine that your company produces its equipment at two different manufacturing sites.
Each manufacturer has its own flashing computer, which is connected to a local network (no internet).
When device production begins, this computer is a subordinate Certificate Authority and issues certificates for each device. Therefore, right after production, each device leaves the manufacturer with everything embedded in the equipment.
In case one manufacturer’s Certificate Authority gets corrupted, other manufacturers are not affected.
Conclusion
Implementing all this in your company is without question quite complicated and requires attention to detail, to avoid making mistakes.
We allow and encourage FoundriesFactory customers to set up their own PKI infrastructure so that they are in control of the security of the device gateway.
If you want to just create your own Public Key Infrastructure (PKI), you can follow the document: Managing Factory PKI. However, in case you want to dive deep into this topic, follow the document Details Of Device Gateway PKI Settings.
Both documents can assist you in creating your own PKI, giving you the responsibility for managing your keys. Being in control of your root of trust also allows you to create a certificate authority for your various manufacturers.
Need more information or want to see FoundriesFactory in action? Just schedule a call with one of our engineers.