Today, product manufacturers have a tough decision on what to build into their IoT products and how to make them stand out. Security is often seen as a “nice to have” feature but is increasingly becoming a “must have”. Simply put, product manufacturers need to pay more attention to security.
IoT and Application Enablement Platforms (AEPs) such as PTC’s ThingWorx, AWS IoT and Microsoft Azure IoT need to deliver a turnkey, plug-and-play IoT security suite that is easy to deploy and manage, trusted and has minimal custom development. These platforms need to leverage a strong security foundation at the device in order to deliver automation and trust.
This job is not easy when looking at the vast plethora of IoT platforms, AEPs and applications available, all of which tend to blind the product maker with science when evaluating which options offer the most value. From a security perspective, the different options that platforms support usually fall two areas:
1) Device certificate-based authentication
2) Tokenization approach
Platforms that utilize certificate-based authentication have adopted an approach that has been deployed across the enterprise for a while now. There is however, still the age-old challenge of how to manage the lifecycle of certificates to devices. You can discover more about this in one of our previous blogs “How PKI has evolved to solve the IoT security issue”.
In this blog I want to focus on the second option, Tokenization, and why a delivery method that Device Authority has created called Delegated Security Management (DSM) is an interesting proposition.
DSM is a delivery model for enforcing policy-driven device security operations that Device Authority’s KeyScaler platform has incorporated. This model is like other tokenized security models (E.g. OAuth) which enable IoT security for embedded devices and gateways, as well as IoT applications and platforms. DSM provides device makers and IoT applications with a plug-and-play IoT security suite that is easy to deploy and manage and provides policy-driven automation for IoT scalability. One of the main advantages of DSM is that it does not require direct integration with the backend application, it utilizes a tokenized security model. This allows IoT applications to instruct devices to validate themselves with KeyScaler during critical events, such as:
- Prior to device onboarding
- When device keys and certificates need to be generated, provisioned or rotated.
- When timing, events or data values indicate that device integrity should be validated.
- When device firmware/software updates are required
- When application-level device authentication is required, and mutual TLS is not supported or manageable at scale. (ThingWorx Step-up Validation or Microsoft Azure IoT Hub SAS Token management)
DSM leverages a trust anchor at the device and whitelisting of devices at the KeyScaler platform as the foundation for its trust foundation and automation.
Why do we need DSM Security Operational model?
Imagine a scenario such as below, where you have an IoT device which connects to an IoT platform or AEP. In this example, the device is an insulin administration pump but could equally be industrial equipment, a gas generator, manufacturing actuator or a vast range of other devices. The important factor is that this device has critical, potentially life-threatening ramifications if the wrong drug dosage was administered to the patient it is connected to. In this example we would utilize DSM for a number of things:
- Trust the device connecting to the IoT Platform / AEP
- Trust the data coming from the device i.e. it’s not a cloned / spoofed device
- Check device authenticity prior to providing a dose of drugs to a patient
- Reduce integration overhead from IoT Platform to IoT IAM
So, there is an assumption here that the IoT platform selected does not use certificate-based authentication and can use a Tokenization approach, such as DSM. Let’s imagine a clinician wants to adjust the dosage of drugs given to the patient connected to this device. Prior to doing this, the IoT platform / AEP can send a DSM instruction to the device to prove its identity and integrity to KeyScaler. The Insulin pump would check-in to KeyScaler and prove its identity/ integrity and on successful validation, will be presented with a signed validation token. This token is passed to the Insulin device to authenticate to the IoT Platform / AEP. Only the IoT Application / AEP can check the signature of the token to check its authenticity. This provides assurance that the insulin pump is authentic and trustworthy prior to modifying the potential lethal dosage.
KeyScaler can support a multitude of applications, use cases and is not only solving the challenges of device trust and integrity with DSM, but also solving a number of other significant IoT security challenges such as:
- Device provisioning,
- Onboarding to the IoT application/cloud service,
- IoT PKI management,
- Integrity validation and authorization checks,
- Device updates.
Without KeyScaler, each device manufacturer must design and build their own unique device security management model and supporting services, individually. Additionally, without KeyScaler, Certificate Authority (CA) and Hardware Security Module (HSM) partners must develop their own, unique PKI delivery and IoT security management services to take advantage of their Key Management Services.
Learn more about our DSM tokenization approach at one of our upcoming events.
You can also hear about our enterprise IoT security blueprint on our latest webinar.