s Modules / Secure Element
First-generation ARTIK devices included a Secure Element for credential storage and security handshake processing. The current generation of "s" modules includes Secure Storage as well as several other security features. Here we'll try to explain the differences and show you how to utilize the features.
*Supports minimal Security API
Why do you need a Secure Element? Didn't we already set up a completely secure Wi-Fi® channel in the SSL/TLS-Secure Links article? Well, that was a private server – yours. With a public server, the security situation gets a little more dicey, and provisioning becomes a lot more cumbersome. The ARTIK Secure Element simplifies all that, using custom provisioning and mutual authentication.
Secure Element Details
Security threats to IoT devices are diverse and real, starting from compromised consumer privacy, up through theft of services and malicious sabotage of connected devices. These security threats can be mitigated if proper security measures are taken in the design and implementation of IoT platforms.
The Secure Element provides services for the secure storage of cryptographic material and other protected content, including random-number generation, key/data secure storage, and certificate handling and processing. It meets the Common Criteria (CC) certification for computer security and for Evaluation Assurance Level (EAL) 5/6+.
ARTIK platform end-to-end security leverages strong hardware security capabilities and support on ARTIK modules equipped with Wi-Fi®. Important capabilities of this infrastructure include:
Provisioning of X.509 certificates, and corresponding keys and identities inside the secure storage of the Secure Element of the modules
Protecting these sensitive assets during execution of cryptographic algorithms dependent on these keys
X.509 certificates issued as part of a PKI trust hierarchy that roots back to the desired root CA, based on a high level of physical security as well as disaster recovery policies
Provisioning of X.509 certificates in the cloud servers interacting with ARTIK devices; server certificates are also issued through a chain rooting back to the same root CA
Establishing a secure channel (TLS/ DTLS) between devices and cloud solutions, and device-to-device communication with strong authentication via unique keys and certificates.
For the default fundamental security of IoT pipeline protection, the key and certificate enables secure device registration with ARTIK Cloud, which ensures the device is genuine and allows message exchange if so.
ARTIK "s" modules additionally offer external provisioning and full access to the security library. The security library is based on TrustZone and the Secure Element, and provides secure storage and cryptographic algorithms running in a secure environment without exposure to the user execution environment.
What you did in the SSL/TLS security articles, as far as generating and copying keys and certificates, is known as provisioning. A way to enhance security is to provision the modules with keys and certificates using secure storage and access methodologies.
First-generation ARTIK modules arrive factory-provisioned with keys and certificates in the Secure Element that are pre-registered for use only with ARTIK Cloud.
Next-generation ARTIK "s" modules offer two additional security models.
Secure Storage: You can set your own keys and certificates inside a trusted storage area where the keys are used for TLS services but can never be read out.
Secure Element: A second key and certificate set can be provisioned in the Secure Element itself, providing the same "bullet-proof" non-volatile security of the first-generation modules – this time using the cloud and PKI of your choice.
Blending elements of all models is possible, and further expands the flexibility of your secure ecosystem. Post-provisioning the Secure Element requires a secure environment similar to that at the ARTIK factory; contact your ARTIK Sales representative for further details.
Where we left off in the SSL/TLS Security series, you had learned how to set up your ARTIK client to authenticate the certificate sent by a server, verifying to the client that the server is legitimate.
- SSL/TLS-Secure Links article: Server certificate » Client
Now we're going to look at the opposite side of that same coin: Letting the server verify that the ARTIK client is legitimate.
- Mutual Authentication article: Client certificate » Server
You'll see that this direction is harder to secure, because millions of mass-produced IoT devices are so easy to hack to steal key information – except for devices using the ARTIK Secure Element.
Secure Element FAQ
All ARTIK modules with Wi-Fi include a Secure Element, implemented in hardware.
What does the Secure Element do? Out of the box, the Secure Element secures communications between the ARTIK module and ARTIK Cloud. It comes pre-loaded with an individual (unique for each module) private/public key pair and device certificate that are pre-registered with ARTIK Cloud. If you "on-boarded" your ARTIK 053, for example, you registered with ARTIK Cloud in this way.
The Secure Element uses the following key technologies to achieve the highest level of security and protection:
• Smart Shield: Custom random layout including memory encryption
• Smart Sensor: Digital fault detection including protection against fault-injection attacks
• Smart Core: High speed secure cryptography engines with a secure low-power CPU
Its inclusion eliminates the headaches of private/public key-pair generation, certificate issuing and managing, and provisioning across the production and supply chain.
When is creation/management of certificates still required? Out of the box, the credentials provided in the Secure Element are used only between the ARTIK module and ARTIK Cloud.
If you implement a local Wi-Fi link, such as between two ARTIK Linux modules or between an ARTIK Linux module and an ARTIK Tizen RT module, you must implement an independent secured link.
Likewise, if you want your connection server to be something other than ARTIK Cloud, you would need to provision that connection yourself.
In both cases, you can do so either by using the manual methods we reviewed previously, or by using the provisioning features of the advanced ARTIK "s" module.
What about ARTIK devices without a Secure Element? ARTIK 020 and 030 edge node devices do not contain a Secure Element, but still come pre-registered with ARTIK Cloud using their MAC address and can be securely on-boarded. The ZigBee / Bluetooth / Thread protocols communicating with these devices introduce their own dynamic key scheme (such as network keys, NWK, for ZigBee) to form an effective security wall within their intended environments.
ARTIK "s" Modules
In general, IoT typically suffers from these four security issues.
|Unsecured Private Key||The private key is often not in a truly secure location, since SW needs access to it to encrypt with it.|
- Private data
|Systems are often hardware-hackable by rudimentary means (like the JTAG programming port) to:
- steal keys to hack similar devices
- steal private information to defraud owner.
|OTA Update Vulnerability||Devices with wireless update capability are especially vulnerable. Routines can be replaced by malicious code that sidesteps security provisions.|
How the Secure Element addresses key security
The Secure Element plugs a large portion of the security hole in an IoT deployment.
|Unsecured Private Key||ARTIK hardware utilizes the private key from inside the Secure Element to encrypt during authentication
– It’s never in software, so no software can hack it
– ARTIK provides an API call to encrypt data using the key.
|Since the private key is never accessible, even a hardware hack can’t reach it.|
How remaining problems require stronger measures
What remains, and what cannot be addressed by the Secure Element alone, are the private data and over-the-air (OTA) update vulnerabilities.
|Hardware‑hackable Data||Need to lock the JTAG port|
|OTA Update Vulnerability||Need to add secure boot, secure OS, secure storage|
Taking these measures goes beyond the ability of the Secure Element alone. It requires changes to the module hardware.
"s" module solution
To prevent malicious images from being loaded, ARTIK offers the "s" module, which:
- Holds the code verification key in hardware
- Locks the JTAG port after programming
- Keeps the system safe during normal operation through hardware-secured memory.
To learn the details about the added ARTIK "s" module hardware, refer to these articles.
– Secure Boot hardware to prevent unauthorized images from executing
– Secure OS with partitioned “secure” and “normal” code execution space
– Secure Storage area for large secure items like certificates
– JTAG Port Lock mechanism.
"s" module identification
ARTIK "s" modules are recognizable by the blue color of their identification sticker.
|Standard module||"s" module|
Many developers and companies will be able to use the features of ARTIK "s" modules with the standard boot code image. However, for those with special needs for in-house boot code customization, there is an additional consideration.
The Secure Boot feature of ARTIK "s" modules prevents boot images from being modified. A proper boot image has a digital signature added at the factory. The devices will not allow the boot code image to be updated unless the code is signed in the correct way.
For companies with the proper security infrastructure, the ARTIK Key Management System (KMS) allows them to add a digital signature to the developer’s boot code image (which otherwise would not execute because of the Secure Boot hardware protection).
If you don't plan to change the boot code image then you won't need to use KMS code signing.
Samsung ARTIK Key Management System. To maintain code integrity tied all the way to the hardware:
The company submits an application to establish identity and trust (much like the process of applying to a Certificate Authority for an SSL certificate) to get a Samsung KMS account. The KMS infrastructure includes a Web portal.
During the development phase, the developer uses a software code-signing tool in the lab to sign code images so they will run on the "s" module.
When boot code for actual field deployment is ready, the developer uses the KMS Web portal to:
– Request key generation specific to that company
– Upload the code to the KMS where it is signed using the key
– Download the signed version.
The developer can then use Samsung-provided or their own custom means to load the new bootloader image.
To get the "big picture", you'll need to understand what the secure registration process achieves. These topics are of primary interest.
Mutual authentication. In the upcoming article, we make trust bi-directional.
Secure API. The ARTIK SDK provides an easy-to-use API to do things like reading back the public key version of the private key stored in your ARTIK module.
Secure registration protocols. The secure registration procedures and protocols used with ARTIK Cloud are described on the ARTIK Cloud Web site.
On-boarding app. Implementing the registration protocols, the Samsung ARTIK app demonstrates the ease of use afforded by pre-registered modules. Contact your Samsung customer representative to obtain the reference design code for this app.
Build Instructions. For complete information on how to build an image, refer to the ARTIK 5/7/10 Advanced Developers articles.