Your Questions Answered: Manufacturing and IoT Device Security

We have conversations with device manufacturers every day around how to develop an overall IoT device security architecture for their current product lines and future product lines. Ideally, this strategy has the proper level security built into each layer of their IoT security stack. This can encompass layers from a device to a gateway and the overall management of your operations.   

The reality is that this is extremely complex and hard to implement.  

Luckily, we’ve got the best minds to help you answer the questions that plague your mind. Today, we’re showcasing the top questions from our recent Q&A series with partner WolfSSL.  

Check out the top questions from our recent Q&A session or watch the full session on demand.  

Where do I start with addressing my IoT device security needs? 

The first thing to understand is that no one vendor will cover all your IoT security layer needs. There simply isn’t one all-controlling vendor out there where you can go for a one-stop-shop. Therefore, you need to start by figuring out what the authentication and data encryption needs you have for the devices in your system.   

Then you need to understand the hardware requirements and limitations you have in order to build in digital certificates and keys into your products. This will be a good start to understanding how your security architecture should evolve over time.   

What are the latest standards for TSL and cryptography?  

We see some major headway in the adoption of TSL 1.3. For a while, the protocol designers did not release any type of standardization.  However, back in 2018, they released a major update they removed insecure algorithms, the number of round trips, and made it easier for engineers to adopt. The reduction of multiple round trips to one full round trip greatly reduces the latency for the TLS connection.   

Fewer round trips required, especially over long distances, minimizes the time it takes to establish that TLS connection.   

Another standard that’s coming soon is datagram TLS 1.3 (DTLS). This will be the TLS 1.3 implementation that also demands perfect forward secrecy. We’re seeing a lot of adoption in industries like automotive, industrial, and medical.   

Everyone should be aware of these trends and recognize if they are on older TLS 1.0. 

What are some strategies for updating the IoT client when the server-side certificate changes or is renewed? What happens if there is no internet for updating?  

When the devices are in the field, without any internet connection, it can be challenging to update these devices without a secure root of trust (RoT). That’s why building in an RoT to your devices should be the top priority. The RoT provides a unique identification that’s not shared with any other device. This way if you have an intermediary client to update an IoT device, it can update without requiring a constant internet connection.   

Many IoT devices live for 15+ years and they also change ownership operators frequently that makes it challenges to track. The way that we embed our Keyfactor agents into devices, we’re proactively building in a repeatable model for updating   

If you can access the device, and the device has enough processing power and memory, Keyfactor can help you with in-field commissioning.   

How do keys get provisioned during manufacturing?   

We know that IoT devices are made all over the world. For cost and supply chain reasons, you might be making these devices outside of your own buildings. However, how do you trust that the keys a third-party is producing in your devices are trusted?   

Keyfactor can help with on-device key generation to build into your firmware. This provides a private key directly on the device without ever needing to be transported from one location to another. This provides an extra level of security that limits your devices from being corrupted from the third party.   

During the on-device key generation, we also help with doing an initial signing request. The signing request sends information back to Keyfactor so we can complete a registration process for your device. This helps ensure that these devices are ones the manufacture has made and allows us to issue a valid certificate.   

What are some examples of where poorly designed IoT security architecture?   

There are lots of examples out there if you do a quick search, but one that comes to mind is in the automotive industry. Back in the mid-2010s, an automotive manufacturer had to recall almost one million vehicles due to a security flaw. This flaw allowed security researches to intercept messages on the internal vehicle network. By having those messaging, hackers could have potentially modified speeds and braking capabilities.  

Another example that recently popped in the news came from a company that made networking equipment. This company accidentally published TSL certificates and private keys into device firmware that would downloadable from their public website.