In the third entry in a series of articles on Java Card 3.1 features, we will be looking at the new Security Services available to developers and detail the IoT Edge Security use cases they enable.
Earlier this month, the Java Card Forum published a White Paper: Java Card for the Internet of Things - Building The Foundation Of End-to-End IoT Security outlining the growing role of Java Card in IoT infrastructures. The new Java Card 3.1 Specification introduces a range of Security Services that support some of the use cases discussed in this White Paper.
We will see that those Java packages (Certificate API, Key Derivation API, System Time API and Monotonic Counter API) can be implemented for example to facilitate IoT Cloud Service Authentication and Device Attestation.
A cryptographic certificate is used to prove the ownership of a public key. It also contains several additional information such as ones related to the key and the identity of its owner. Cryptographic certificates are critical in modern cryptography and serve as a basis in Public Key Infrastructure to establish trust in between different entities. A notable example of protocol using cryptographic certificates is the Transport Layer Security (TLS) protocol. Based on certificate chains, a mutual authentication (both server authentication and client authentication) can be established from which a unique and secure communication channel is created in between the two parties.
The javacardx.security.cert package is an innovative and efficient way to manage cryptographic certificates such as X.509 certificates for memory and resource-constrained devices.
The new Java Card 3.1 API allows developers to do the following:
parse a certificate with no intent to store it, e.g because this is the certificate of a certificate chain temporary used during a server authentication phase
build a certificate (parse and store) which creates a dedicated object, e.g for persistent root or device certificates
filter on fields and extensions to optimize memory representation
verify a certificate signature at the time it is parsed or built. This speeds up the verification process and avoids creation of a certificate object only with the purpose of verifying it. In the meantime, it is possible to access and reuse the public key of such verified certificate later on.
With this API, it is possible for instance to verify a certificate signature, select and check some of its fields and extensions and access its public key, without having to create a dedicated certificate object potentially useless in the future.
One can as well build a certificate object (e.g for root certificates) that will be reused later on, while deciding on fields and extensions that have to be associated to this certificate object, storing only useful components of the certificate. This is shown in the figure below:
With this mechanism, an applet has an efficient way to verify a certificate chain, check sensitive certificate fields and keep track of trusted public keys.
Pseudo Random Functions (PRF) and Key Derivation Functions (KDF) are widely used in cryptography to derive sensitive data such as a secret key. They permit in particular to stretch a secret or to derive multiple keys from it.
A typical usage is the derivation of a password to store a derived value without having to store the initial password value. Another common example is the derivation of the shared secret established by a Key Agreement operation like Diffie Hellman (DH) or Elliptic-curve Diffie Hellman (ECDH). A last example is the TLS handshake protocol, using a PRF applied to a shared secret in between a client and a server to generate the cryptographic block material used during a given TLS session between the two peers.
Java Card 3.1 introduces the package javacardx.security.derive. The class DerivationFunction permits to manage both PRF and KDF algorithms. Eight algorithms are proposed, allowing support for the International Civil Aviation Organization (ICAO) or TLS protocols for instance. However the mechanism introduced by the API is generic and easily extensible. The current list of algorithms is:
Besides, the API guarantees both the security of the derivation keys and the derived keys by encapsulating them into trusted objects.
Numerous security protocols use monotonic counters - counters with a value that can only increase - to prevent replay attacks.
Once the value of a monotonic counter has been used, the counter is incremented (typically by 1). Thus if a counter value has been attached to a given protocol payload at a certain point in time, there is the guarantee that the same counter value cannot be reused and attached to the same protocol payload later on. It allows a third party consuming the protocol payload to know if it has been already used by checking the counter value.
Device attestation (also named Remote attestation) is an example of payload that needs to be protected against replay attacks. A remote attestation is a signature of software measurements running on a given device, and sent to a third party. The third party can check if a device is running unaltered software (or not), being sure the attestation is current and not replayed from the past.
External secure storage is another example requiring a monotonic counter. A large amount of data can be stored in the flash of a device external to the Secure Element. In this case the cryptographic material and operations guaranteeing data confidentiality and integrity are managed within the Secure Element, but the protected data are stored in an external area accessible by untrusted applications. Anti replay is then critical since secure storage contains sensitive data like DRM licenses, PIN entry tries, payment receipts ...
A monotonic counter may relate to a given protocol session and may be considered as transient e.g the counter used for an AES ciphering in counter (CTR) mode. In other cases, it may be an absolute value bound to hardware and may be persistent e.g the counter for a secure storage or the counter of a device that is attached to a signed device attestation sent to third parties.
The javacardx.security.util package and its MonotonicCounter class allow the creation of multiple monotonic counters up to 64-bits each with a value in different memory spaces:
A MonotonicCounter instance with a transient value which is cleared and reset when the corresponding clear event occurs (deselect or reset). It should only be used during a session to protect data with the exact same lifecycle. The applet has to guarantee that updating the counter is not updating non-volatile memory.
A MonotonicCounter instance with a persistent value. It can only be increased until it reaches its maximum value and cannot be reused afterwards. The applet shall take into account that updating the counter value may imply updating non-volatile memory.
The MonotonicCounter methods allow for regular operations such as: initialize counter, increment counter, compare value and get value operations. Besides, two critical security properties are guaranteed by the API:
The update of the counter value is atomic for all operations.
Even if a transaction is in progress, the update of the counter value shall not participate in transaction and cannot be rolled back.
Timestamping and time interval calculation are important security operations. Timestamps permit to record or check the time at which an event occurred. Estimating time interval allow to limit the duration of a transaction for instance.
Java Card 3.1 introduces the package javacardx.framework.time with two classes:
SysTime serves to retrieve the uptime that is the time elapsed since system boot. It does not require an internal clock. Coupled with an origin, it permits to simulate a system time.
TimeDuration models a quantity or amount of time with a microsecond resolution. The model is a directed duration meaning that the duration may be negative. A TimeDuration is up to (2^63)-1 microseconds and can be accessed using other duration-based units, such as milliseconds, seconds, minutes, hours and days. Several operations like the comparisons, conversions, plus, minus operations are supported.
System Time can support a variety of use cases related to device security. For example we can consider an IoT device managing a temperature sensor in a chemical industry. This monitoring system is critical and needs to react to unexpected temperature variations. With the new I/O mechanism introduced in Java Card 3.1 and using the System Time API an applet has the ability to retrieve a temperature value and to assess the elapsed time since the beginning of the measurement in a secure manner. If the time is too short or too long compared to the average expected value, this is reported to the monitoring system that will trigger corrective operations like changing the sensor or checking for a corruption.
Java Card 3.1 introduces four Security Services:
They permit to address many IoT use cases demanding security:
|November 8, 2018||Applet Deployment Update|
|November 19, 2018||New I/O and Trusted Peripherals|
|November 27, 2018||Security Services|
|December 6, 2018||Core Platform Enhancements|
|December 14, 2018||New Cryptographic Extensions|