TalkingTrust with Thales and Keyfactor: IoT

There are many reasons why manufacturers connect their products to the Internet – whether it’s connected cars, medical devices, industrial machines, or consumer products. Connectivity enables powerful, revenue-generating capabilities, from data telemetry and runtime analytics, to predictive maintenance that allows you to anticipate warranty recalls and manage them effectively.

Today’s vehicles run as much on code and connectivity as they do on electricity or gasoline, especially as new safety and accident avoidance features are rolled out. Many auto manufacturers today have the ability to remotely update software to fix vulnerabilities or even upgrade functionality.

Imagine a world where the retail value of your car actually grows over time – that’s now becoming a reality. It’s also enabling manufacturers to respond faster to security vulnerabilities, market demand, and even natural disasters.

In 2017, Tesla sent an over-the-air update to their Model S and X vehicles to extend maximum battery capacity and driving range, which allowed owners to drive an extra 30 miles outside the evacuation area as Hurricane Irma beared down on Florida.

These are the types of capabilities we’ve come to expect from our vehicles. The problem becomes – how do we make sure we’re securing these “driving data centers” against the risks and threats that lurk in the Internet? It’s a complex challenge that we’re only just beginning to address.

For al the benefits of connectivity, there are always challenges. Let’s break down some of the core reasons why securing these connected devices is so hard.

They’re attractive targets

First off, connected vehicles and IoT devices are highly attractive targets to hackers. That’s because many vendors have not incorporated adequate security controls within their connected products, which is driven – at least in part – by a general lack of cybersecurity expertise and tight product delivery timelines and margins.

Unlike servers and devices running in enterprise networks, IoT devices are typically shipped direct to consumers, without any control over the network or environment they run in. This makes them attractive targets for botnets, crypto-miners, and takeover attacks.

They have design constraints

Faster development lifecycles and feature delivery often take priority over security to get products to market. There is also less hardware and compute power to work in your typical IoT device when compared to traditional devices, so embedding security becomes a matter of choice, rather than necessity. For instance, running heavy software-based agents just isn’t an option in an embedded pacemaker or insulin pump device.

The same rings true for encryption and authentication. Depending on the device you’re manufacturing, hardware constraints may mean that Elliptic Curve Cryptography (ECC) makes more sense to use instead of RSA. Asymmetric encryption may require too much processing power for certain devices, making symmetric keys the only option. These are the types of conversations we have with our clients to find the best fit for security without compromising on time-to-market.

The supply chain is complex

The number of different vendors involved in the design, development, build, and delivery of connected products is a result of years and years of collaboration, but everyone needs to be on the same page when it comes to security.

Co-ordination is key. However, ensuring that security is handled correctly in untrusted and remote manufacturing environments is something the industry as a whole is still struggling to solve. In many cases, this leads to the insecure storage, handling, or sharing of cryptographic keys between vendors, which results in key theft or compromise.

They’re difficult to patch and update

The ability to update devices is critical, not only to enable new features, but more importantly to fix sudden and unpredictable vulnerabilities or malfunctions (e.g., weak cryptography, software bugs, malware, etc.). Many vendors deliver connected products to market without adequately planning and testing software and security update mechanisms.

Over-the-air (OTA) software and firmware updates must be delivered securely and effectively. Recent events highlight the need to secure the software supply chain, from code quality checks and secure code-signing processes to securely protecting the private keys used to sign code. You also need to ensure that devices can verify the signature to ensure that only authorized code can run on them, not malicious malware spoofed with another signature.

Another consideration is unreliable networks. For instance, if a car drives into a tunnel or sits offline in a garage for winter months during your software update, how can you ensure the update is installed when that vehicle comes back online?

Design and product lifespans are long

Many of these devices take years to design, test, and manufacture before they ever reach the market. Adding security late in the game is much more difficult and costly compared to a ‘security by design’ approach. On the other end, the IoT device lifecycle from design to end-of-life (EOL) can stretch anywhere from days to more than 20+ years (think about modern cars).

Security isn’t static. Many IoT products in the market today will outlive the validity of cryptographic algorithms they use to protect devices and encrypt sensitive data. Manufacturers and hardware suppliers, especially in those the automotive industry, need to plan ahead for the eventual mass rotation or replacement of keys and certificates across their fleet.

The automotive industry is a primary example of how Internet-based threats can impact the privacy and safety of end users (aka drivers). Security researchers have proven multiple times that exploiting connected vulnerabilities in modern vehicles is not only possible, it’s also practical and feasible.

Some examples of these threats include:

• Vehicle operation threats: manipulation of data/alerts from interconnected systems, or remotely activating driver functions, such as braking or acceleration.
• Remote start threats: a compromised digital key fob (i.e., due to weak encryption) allows hackers to gain authorized access to a vehicle.
• Data privacy threats: man-in-the-middle attacks compromise transmission of personal data, vehicle location, travel history, etc.
• Electronic control unit (ECU) threats: malicious firmware updates act as a ‘trojan horse’ which allows the hacker to imitate trust and remotely access vehicle control systems.
• Infotainment and remote diagnostics threats: a remote attack via linked mobile devices or altering information from vehicle diagnostics systems.

Securing the next generation of connected vehicles and IoT devices demands a new approach with a focus on security by design and crypto-agility throughout the device lifecycle.

So, how do we address these challenges? There are many different layers of security involved in protecting connected devices, so security should start with a high-level architecture of the IoT stack and connected ecosystem.

Edge Devices

Think about IoT devices and the components within them, such as electronic control units (ECU) and the gateways that aggregate and transfer data. For starters, every device should have a unique, trusted identity that is not duplicated or shared with other devices.

• Device Identity: Provision a unique ‘digital identity’ by embedding a trusted PKI-based asymmetric key pair during manufacturing or device provisioning. Ideally, the private key should be generated on the device (known as On-Device Key Generation or ODKG).
• Firmware Signing: Ensure that over-the-air (OTA) firmware updates are signed and code-signing keys and certificates are protected inside a hardware security module (HSM), such as a Thales SafeNet HSM.
• Secure Boot: Use in conjunction with firmware verification to ensure the device only boots up after it has validated the state of the trust in the device.

Management Platforms

Once you’ve figured out how to embed security at the device level, you need to next consider how to ensure security at the management and backend operations level. Whether it’s a power turbine or an insulin pump, the need for data to be collected, monitored and analyzed is what really drives the value of IoT – but security at this layer is essential.

• Device Authentication: TLS has been used to secure the Internet for decades, making it an ideal fit to enable authentication or mutual authentication (mTLS) over connections such as Wi-Fi, Bluetooth or 5G Networks.
• Data Encryption: Asymmetric encryption won’t cover everything. Symmetric keys should be used to encrypt and protect data-at-rest on devices and within databases or cloud services. In some cases, you digital certificates may not be an option due to hardware constraints, but symmetric keys should always be used to protect data.

IoT Operations

If you’ve encrypted data and established secure connections correctly, you can ensure end-to-end protection of data, and allow that data to be decrypted and accessible at the operational level based on trust.

When we look at designing a security architecture for IoT devices, it starts with understanding what identities you need to create, how they need to be provisioned, and the infrastructure that’s needed to support that.

An end-to-end security approach should include the ability to support high-volume issuance of trusted keys and certificates to components on the factory floor and in the field, the management of those identities through their lifecycle, and secure software/firmware signing processes.

Thales and Keyfactor together provide the infrastructure and tools needed to support these requirements in complex environments, such as automotive and medical device supply chains.

Hosted PKI as-a-Service: Privately-rooted, highly available PKI delivered as a service from the cloud with built-in Issuing and Root CA protection via Thales Cloud HSMs. You can also leverage your existing on-premise PKI and HSMs.

• IoT Identity Management: End to end management of the encryption keys and digital certificates from issuance, provisioning, replacement and revocation.
• Secure Signing: Centralized and secure firmware signing workflows to deliver trusted OTA updates to end-devices – backed by a secure Thales HSM to ensure code-signing keys are safe from theft or misuse.
• Ecosystem Integration: APIs and plug-in integrations to integrate with existing on-premise HSMs, crypto-libraries, cloud platforms and IoT applications.

Learn more about how Keyfactor and Thales make it possible for manufacturers to embed security identity and updateability into devices from the start.