Embedded Security for IoT
Hardware – Software – Cloud
Today, nearly every company is a digital security company — or should be. Security and keychain management starts with design and continues as long as the product is in use. Striking a balance between user-friendly and secure requires a thoughtful balance of technology with a deep understanding of the tolerances of the target market. Secure hardware design often starts with specially provisioned authenticity chips, which not only validate the device but also prevent the manufacturer from producing non-sanctioned units. Depending on the device, securing against a variety of physical attacks and hacks in addition to the constant remote software attacks is necessary. Best practices for secure software development include regular updates to address new threats as they arise, and when updating, it is vitally important to ensure that it can only be updated by a verified source. Security continues through the cloud software and the end-user apps. Most importantly, every aspect of the security must be maintained — a chain is only as strong as its weakest link. Cardinal Peak’s end-to-end design capabilities confirm that no holes have been left in your security architecture.
Embedded Device Security Examples
Cardinal Peak supports innovative embedded security for Internet of Things including hardware and software solutions such as the projects below. If you’re looking for embedded security consultants or a penetration testing company, please contact us.
Resources for Embedded Security for IoT
Josh Datko is the founder of Cryptotronix, co-founder of Keylabs, Inc. and a panelist on our July 15th end-to-end product security webinar. Get to know Josh and register to hear advice for building security into every aspect of an embedded device.
Hash-based message authentication code, or HMAC, is an important building block for proving that data transmitted between the components of a system has not been tampered with. It is a widely used cryptographic technology. I recently came across its use in an RFID system.
FAQs for Secure Hardware and Software Development
How does Embedded Security for IoT Devices differ from general Embedded Security?
IoT device security adds another layer of complexity for embedded security. For wireless IoT devices, it is important to protect against man-in-middle and other wireless intrusion strategies. Generally, IoT devices are designed to only connect to one cloud service as a means of ensuring the device is not being used by a hacker to eavesdrop. Since these are connected devices, they can be misused to become spying devices. At manufacture, credentials with unique keys are installed in the device to ensure only authorized access to your cloud service. An over-the-air (OTA) firmware update is one of the compelling features for connected devices but requires the proper precautions to prevent unauthorized code from being installed. These are just a few unique considerations for IoT security. To read more, see our blog Security Best Practices: From IoT to HIPAA.
What does Secure Embedded Software Development entail?
There are many facets to embedded security. Like all security, there is an important balance that needs to be maintained between usability and security. It is easy to make a device so secure that no one can use it. Some of the things we think about in embedded security include Secure Boot, not allowing any default usernames/passwords, and using TLS or equivalent. Of course, the list goes on and on. Read more in our blog What is the weakest link in your IoT product security chain?
How can I ensure my IoT Device has a Secure Hardware Design?
Designing secure hardware involves many aspects that are tuned to the exact application. For IoT devices we often design in device authentication hardware to ensure all devices on the network are genuine. For some applications, it is necessary to design against physical attacks where someone uses physical means to gain control over or access to an otherwise secure device. There are also the obvious items, like making sure all debug interfaces are disabled in production. To read more about a device we designed that involve significant hardware security, check out this case study.