Filter results by

Secure OS and TLS

Operating in a secure ecosystem requires a processing environment with both a secure OS and secure storage. Implementing such an environment is not trivial; ARTIK provides both the implementation and the means to interact with it.

A significant part of the security picture involves establishing and operating SSL/TLS-secured links. The mutual authentication required is part of the native ARTIK "s" module secure processing and secure storage infrastructure.

Trusted Execution Environment

The Samsung ARTIK 5 and 7 family modules support the Trusted Execution Environment. TEE provides a fully-isolated and secured operation environment to applications requiring a high degree of security, as well as the full capabilities and power of the application processor environment.

TrustZone

The Samsung TEE implementation is based on the ARM® TrustZone® hardware architecture. TrustZone allows for the complete separation of the Trusted Execution thread from regular operation. The TrustZone hardware enables the isolation of system resources such as specific memory sections and specific peripherals so they are only accessible by way of the trusted environment.

A TrustZone CPU enables the operation of two completely-separate threads:

  • a secure thread that has full privileges to access all system resources
  • another thread that is used for general applications and is restricted from accessing the specific resources designated for secure operation.

Inclusion of the basic TrustZone hardware support is a requirement for the implementation of a proper TEE environment. An operating system and applications that utilize this hardware capability and are coded with the proper methodologies to guarantee their security then need to be deployed.

Surprisingly, many systems that are based on platforms that include mechanisms such as TrustZone have not implemented true TEE functionality due to the complexity and required expertise. ARTIK implements the hardware, the secure OS, and secure storage, and provides applications with a simple API to utilize the features.

» Loading TrustZone OS

Secure Processing Options

The Samsung ARTIK platform offers all of the required software support for a hardware-based TEE implementation pre-integrated into its firmware support. The software included in ARTIK modules includes two separate options to meet different needs.


Samsung SEE. Samsung Secure Execution Environment (SEE) provides a full TEE implementation of a secure OS through API calls for access and communication from a non-secure operating system. Samsung TrustWare is the underlying security component. The environment supports basic security API calls.

  • Key Manager: generate, set up, and remove keys
  • Certificate Manager: generate, manage, and verify certificates and signatures
  • Crypto Manager: AES and RSA encryption and decryption
  • Secure Storage Manager: initialize and manage the Secure Storage
  • Post-Provisioning: Inject and provision a certificate and key into the Secure Element.

The Secure Element comes pre-provisioned for full, secured access to ARTIK Cloud servers. With ARTIK "s" modules, you can use security API calls to extend this access to include other servers and clouds as well.

To program using the Secure Execution Environment: Refer to the Security API articles.


Trustonic TEE. ARTIK modules also support the Trustonic TEE, offering pre-integration of the Trustonic environment (named Kinibi). Users developing custom TEE applications or operating multiple, isolated TEE applications will find the Trustonic TEE ideal.

To program using the Trustonic TEE: Contact Trustonic for more information.


Mutual Authentication

In an earlier article, we reviewed how to authenticate from server to client so that the client can trust the server. But how does the server know whether to trust the client?

This becomes a significant problem in the IoT world where there are MANY tiny clients connecting to the network, not all of them necessarily friendly.

Mutual authentication between server and client is an optional but highly recommended scheme for greater security. To authenticate both ways is very simple: Use the same method as described previously for Server authentication, but for the Client this time.

For setup: Create a Client (as opposed to server) private key and certificate.

At connect time:

  • Server sends its certificate to client (as before)

  • Client sends its certificate to server (new)

That's all easy enough. The difficult part is: How do you keep the client key secure?

Consumer systems (PCs) and most IoT devices do not typically implement client certificates. In the ideally secure IoT world, they all would.

Review: PKI and Security Credentials

Let's quickly revisit and summarize what security we've put into place up until now for Wi-Fi connections.

Linux systems secure wireless communications with SSL/TLS. They use Public Key Infrastructure (PKI) to “authenticate” that a connected device is legitimate by verifying its credentials against a local copy (literally checking its ID).

How is this implemented?

  • Create and then load credentials on each server and client, a one-time setup

One-time setup. In the Secure Deployment article, we used the OpenSSL command set to create security credentials. Here we summarize the steps we used for the Server (applies to ARTIK or any Linux PC).

  • Generate and store securely a “private key” – no one aside from protected core services within the server is ever meant to see this key.

  • Generate a “certificate signing request” (CSR) based on the private key.

  • Send this CSR to be “signed” by a trusted Certificate Authority (CA) like GoDaddy or Symantec (you pay for this service).

  • Upon verifying the validity of the requester, the CA provides a “server certificate” tied to your server, as well as their own “CA certificate”.

    – Server keeps the server certificate.

    – You pre-copy the "CA certificate" to each client that will need to trust that server.

How does it operate?

  • On initial connection, the devices authenticate each other’s credentials.

  • Once authenticated, they agree on a set of Session Keys that they use to encrypt data exchanges for the rest of that session.

Operation upon connection. The server now has its own private key and the derived “server certificate”.

Each client now has a “CA certificate” whose Root of Trust is included as part of the server certificate (making the server certificate trustworthy to the client).

Every time a server and client want to connect:

  • The server transmits its server certificate (its credentials) to the client.

  • If the client sees that the CA Root of Trust listed in the server certificate matches the one in the CA certificate copied to it previously, it trusts the credentials of that server.

Why does this secure the data?

  • In its server certificate, the server is sending the client the public key version of its private key.

  • The server next encrypts a message using its server private key, and sends it to the client.

  • A client can decrypt this message using only the public key in the server certificate.

  • Using that message to agree on a cipher set, the two set up an encrypted channel that is safe for further data exchanges.

ARTIK Secure Element + ARTIK Cloud PKI

As we saw in previous discussions, manually setting up each secure server or client requires that you:

  • generate a private key
  • generate its associated certificate containing a public version of the private key
  • have it "signed" by a Certificate Authority you can trust, possibly for a fee
  • copy certificates as needed.

If your link is between your platform and ARTIK Cloud, ARTIK modules make this easy. The Secure Element on each module is pre-loaded with:

  • a unique private key
  • its associated certificate containing a public version of the key
  • a certificate establishing ARTIK Root CA as your Root of Trust (no fee!)
Topic using Manual way using ARTIK Secure Element
Generate private key generate using openssl pre-loaded
Generate associated
server or client certificate
generate using openssl pre-loaded
"Sign" each certificate pay to have each one signed by a trustworthy CA pre-signed, no fee
Copy the certificates copy from generated location to each device pre-copied

ARTIK 5/7 modules, as well as ARTIK 05x modules, all come pre-programmed in this way. The server is ARTIK Cloud, whose server certificate is also rooted to the ARTIK Root CA certificate.

The private key is in the Secure Element and cannot be read or hacked by anyone.

  • ARTIK provides API calls to let Secure Element hardware utilize the private key for encryption without exposing it.

  • Even a direct hardware hack can’t get to the private key.

The short tutorial in the Secure API article lets you try this out to get a better feel for how it works.

Encryption and Authentication Details

One of the most basic security measures is to provide communication security – preventing unauthorized access of all communication passing between two entities in the IoT system. It blocks 3rd-party listeners from decoding any of the ongoing traffic, and eliminates the ability to inject unintended traffic into the connection.

Two most important requirements of communication security are:

  • Encryption – the process of protecting a payload being communicated between any two entities

  • Authentication – the process that allows one party to validate the identity of another party.

The Samsung ARTIK ecosystem provides a full solution for secure communications between ARTIK module-based devices and Samsung ARTIK Cloud. The ARTIK solution provides all the necessary software stacks and protocols necessary for secure connectivity to other IoT products and services.

Encryption

A payload is encrypted on one side of the link and decoded on the other side. The two sides need to share a secret key that is used for the encryption process. A non-authorized listener who does not have the key cannot decode the traffic even if the encryption algorithm used for encrypting the traffic is known.

ARTIK provides hardware acceleration (Crypto Engine) for AES and RSA encryption and decryption. It uses Elliptic Curve Diffie–Hellman (ECDH) for encryption key sharing, which provides a high level of protection with low power consumption.

Authentication

Authentication is based on the knowledge of a shared secret between the two parties initiating the link or by using public cryptography based signatures and certificates. ARTIK provides a Public Key Infrastructure (PKI), which is used to generate and apply unique certificates and key pairs on each ARTIK Module during manufacturing.

The PKI standard defines a set of roles, policies, and procedures to create, manage, distribute, use, store and revoke digital certificates, and manage public key encryption. This facilitates the secure electronic transfer of information where simple passwords are an inadequate authentication method, and more rigorous identity proof and information validation is required. ARTIK uses Certificate Authorities to validate different levels of certificates.

ARTIK Cloud and devices use Transport Layer Security (TLS) and Datagram TLS (DTLS) protocols for a secure communication channels. Over TLS/DTLS, ARTIK Cloud authenticates ARTIK devices using a certificate/key-pair stored on each ARTIK device. The certificate/key-pair is stored in a highly secure location, the Secure Element. The certificate/key-pair cannot be altered or tampered with once they have been flashed onto the ARTIK device.

Also, as part of the authentication process, matching session keys are created to establish a secure session for data transfer between the ARTIK device and ARTIK Cloud, which are then used to encrypt/decrypt the traffic using AES encryption. One may also store an HMAC key and asymmetric key pair into secure storage. This may be used to set up a secure connection with a third party cloud service.

TLS Handshake

A full discussion of TLS handshake is beyond the scope of this article. However, once you have become familiar with it, there are additional details that you will need to understand with respect to ARTIK. Refer to the TLS handshake section for an overview of the operation that is specific to ARTIK modules.


Last updated on: