MCSDK UG Chapter Developing Security

---

---

Developing with MCSDK: Security

Last updated: 03/08/2015

Overview

Learn about security features offered in the SDK.

Secure storage for storing long-term secrets

Overview

Secure store is a software representation of a hardware token, which provides facility to securely store and retrieve longterm device secrets in NAND.

This have following features

• The secure store filesystem is encrypted and stored in NAND with a AES128 bit key called securestore encryption key
• The securestore encryption key is stored in NAND with a separate UBI volume
  • The securestore encryption key' is stored as a key blob in NAND with a header and checksum to check for integrity
  • In non-secure device the key blob is stored in plain text
  • In secure device the key is encrypted and signed by boot keys and stored in NAND
• The encrypted and signed secure store file is stored in NAND on two separate UBI volumes to increase reliability
• Secure store services are provided by a daemon process called softhsm-daemon
• Application access to secure store is through PKCS#11 APIs provided by the secure store library(libsecstore.so)
  • This library serializes PKCS11 API requests and sends to softhsm-daemon.
  • The communication between application & daemon is using Unix domain socket IPC.
  • softhsm-daemon processes the PKCS11 requests and provides response to the application
  • Applications in this context will be strongswan, libp11 etc.
  • OpenSSL applications like TLS client/server & CMPv2 client will be accessing secure store services via the OpenSSL engine interface.

Following is the startup sequence wrt. secure store

1. U-Boot reads the securestore encryption key blob from NAND UBI volume
   1. In secure device: Authenticated/Decrypted key blob is placed in internal memory
   2. In non-secure device: The key blob is in plain text, and placed in internal memory
2. During Linux kernel boot, the UBIFS secure store volumes are mounted in filesystem using fstab
3. The Linux init script starts softhsm-daemon
4. The softhsm-daemon reads/parses softhsm config file from Linux filesystem for the following
   1. location and size of internal memory
   2. location of securestore encryption key
   3. securestore file paths
   4. Unix domain socket names to be used for IPC
5. The softhsm-daemon waits on a Unix domain socket, the socket name is provided in the softhsm config file

Internal memory for secure store

Secure store uses internal memory (MSMC SRAM) to keep the working copy of secure file system. 64KBytes of MSMC SRAM starting from address 0x0c000000 is used by secure store and this memory range must not be used by any other DSP or ARM application. If configured, Secure store can also use internal memory to maintain heap for dynamic memory allocations of crypto library(OpenSSL), in which case it will consume 38KB of memory from the reserved 64KB.

Secure store ubifs volumes

• Following UBIFS volumes used for secure store, the volumes names are as follows
  • securedbv0, securedbv1: Two volumes to store encrypted and integrity protected filesystem blob
  • Securestore encryption key file blob is present in boot volume
• Sample UBIFS config file is provided in <release_folder>/sc_mcsdk_linux_<version>/images/ubinize.cfg

Creating securestore encryption key blob

A raw text or binary key file can be converted to the format required by secure store using securestore-formatkey.py script provided in <release_folder>/sc_mcsdk_linux_<version>/bin file. Note that the key has to be a 128bit AES key.

<release_folder>/sc_mcsdk_linux_<version>/bin/securestore-formatkey.py --input ./aeskey.txt --output securedb.key.bin

• Note: The u-boot will use "securedb.key.bin" file name to access load the key from volume "boot"
• Please see the script help <release_folder>/sc_mcsdk_linux_<version>/bin/securestore-formatkey.py --help for other usage details
• In case of secure board, this file has to be processed further, please see MCSDK-SECDEV user guide for further details

Creating securestore filesystem ubifs volume image

The default UBI volumes (securedbv[0-1].ubifs.img) are provided in the release package. The following sequence of commands will create securestore filesystem image ubifs partition export PATH=<release_folder>/sc_mcsdk_linux_<version>/bin:$PATH

rm -rf ./securedbv0 ./securedbv1 mkdir ./securedbv0 mv <path to filesystem blob> ./securedbv0/securedb mkfs.ubifs -r ./securedbv0 -F -o securedbv0.ubifs.img -m 2048 -e 126976 -c 22

mv ./securedbv0 ./securedbv1 mkfs.ubifs -r ./securedbv1 -F -o securedbv1.ubifs.img -m 2048 -e 126976 -c 22

Secure store token initialization

An empty, encrypted & initialized token is present in the default filesystem. In case it is needed to re-initialize the token, it can be done on the target using softhsm-util command. The default PINs are 1234. NOTE: Secure store has a restriction that the SO PIN & User PIN be set the same. softhsm-util --init-token --slot 0 --label token-0 --module /usr/lib/softhsm/libsecstore.so.1

softhsm-util --show-slots --module /usr/lib/softhsm/libsecstore.so.1 For more information see help for the tool softhsm-util --help NOTE: A reboot of the system is needed after initializing the token.

Using Strongswan with secure storage

Storing credentials

• RSA Key pair
  • RSA key pair to be used by Strongswan during IKE negotiation has to be generated and stored on the secure store.
  • Key generation/storage can be done through OpenSSL command line or via engine API programmatically.
• X.509 Certificate
  • End entity certificate is issued by a certification authority, and needs to be brought into the secure store
  • In a production system this would be done by CMPv2 client.
  • For lab setup
    • Certificate issuance can be done using command line tools provided by Strongswan or OpenSSL.
    • This process will require access to the RSA public key of the end entity. Secure store solution provides an OpenSSL engine command to retrieve the Public key from store.
    • The issued certificate can then be written to secure store using OpenSSL engine commands.
• CA certificate also needs to be in the secure store and can be written using OpenSSL Engine commands.

PKCS#11 plugin configurations

To use the strongswan pkcs#11 plugin, PKCS#11 module has to be configured in /etc/strongswan.conf.

Configuration Keys specific to pkcs#11 plugin are explained in the PKCS11Plugin wiki.

Default configuration provided will be: libstrongswan { plugins {

   pkcs11 {
     modules {
       secstore {
         path = /usr/lib/softhsm/libsecstore.so.1
       }
     }
   }
 }

}

PIN configurations

Soft token will have a static PIN. Following wiki explains the format for configuring a static PIN in the file /etc/ipsec.secrets PIN Secret.

Private Key configuration

The RSA private key to be used from the smartcard is specified as part of the PIN configuration with the format: %smartcard[<slotnr>[@<module>]]:<keyid> e.g.

: PIN %smartcard0@secstore:04 1234

Certificate configuration

Certificates stored on smart cards will get loaded automatically when the IKEv2 daemon is started. You don't have to specify leftcert=%smartcard in ipsec.conf (it actually will fail if you do so). Instead the first certificate matching the “leftid” parameter is used.

CA certificates are also automatically available as trust anchors without the need to copy them into the /etc/ipsec.d/cacerts/ directory.

conn alice

     left=158.218.103.42
     leftprotoport=udp/5000
     #leftcert=bobCert.der
     leftid="C=US, O=TestInc, CN=bob"
     right=158.218.103.108
     rightid="C=US, O=TestInc, CN=alice"
     rightprotoport=udp/5000
     keyexchange=ikev2
     type=tunnel

lifetime=24h auto=start

PKCS11 engine commands for OpenSSL

Following commands are provided by the OpenSSL engine (engine_pkcs11) to interface with secure storage

• SO_PATH: Specifies the path to the 'pkcs11-engine' shared library
• MODULE_PATH: Specifies the path to the pkcs11 module shared library
• PIN: Specifies the pin code
• VERBOSE: Print additional details
• QUIET: Remove additional details
• INIT_ARGS: Specifies initialization arguments to the pkcs11 module
• LIST_OBJS: List the objects from token
• STORE_CERT: Store X.509 certificate to token (DER format)
• GEN_KEY: Generate & store RSA key pair to token
• DEL_OBJ: Delete objects from token
• GET_PUBKEY: Get Public Key from token (PEM format)

Following is the listing of these commands

• Command to load the engine dynamically and set the PIN

engine -vvvv dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/softhsm/libsecstore.so.1 -pre "VERBOSE" -pre "PIN:1234"

• Command to enable verbose

engine pkcs11 -pre "VERBOSE"

• Command to set the PIN

engine pkcs11 -pre "PIN:1234"

• Command to list the objects on slot 0

engine pkcs11 -pre "LIST_OBJS:0"

• Command to store certificate to token

engine pkcs11 -pre "STORE_CERT:slot_<slot>:id_<id>:label_<label>:cert_<filename>"

e.g.

engine pkcs11 -pre "STORE_CERT:slot_0:id_03:label_tcert:cert_caCert.der"

• Command to generate a RSA key pair

engine pkcs11 -pre "GEN_KEY:slot_<slot>:size_<size>:id_<id>:label_<label>"

where <size> is the RSA key size in bits

e.g.

engine pkcs11 -pre "GEN_KEY:slot_0:size_2048:id_04:label_tkey"

• Command to get the Public key from token

engine pkcsc11 -pre "GET_PUBKEY:slot_<slot>:id_<id>:label_<label>:key_<filename>"

e.g.

engine pkcs11 -pre "GET_PUBKEY:slot_0:id_04:label_tkey:key_tkey.pem"

• Command to delete an object from the token

engine pkcs11 -pre "DEL_OBJ:slot_<slot>:type_<type>:id_<id>:label_<label>"

where <type> is the object type (privkey/pubkey/cert)

e.g. to delete certificate

engine pkcs11 -pre "DEL_OBJ:slot_0:type_cert:id_03:label_tcert"

e.g. to delete a public key

engine pkcs11 -pre "DEL_OBJ:slot_0:type_pubkey:id_04:label_tkey"

e.g. to delete a private key

engine pkcs11 -pre "DEL_OBJ:slot_0:type_privkey:id_04:label_tkey"