Resources / Technical articles / Providing a consistent crypto API throughout the Kinibi ecosystem

Providing a consistent crypto API throughout the Kinibi ecosystem

Mark Wooding

This year’s 400A release of Kinibi contains many significant cryptographic enhancements. For example, it introduces elliptic curve cryptography, which can be used for public-key encryption and signatures using smaller keys and less energy than RSA.

It introduces the AES-GCM authenticated encryption mode, which protects a message’s privacy and integrity in a single operation; and (on devices with a sufficiently capable processor) it offers improved performance for AES, hashing, and public-key crypto.

This is all very well for customers who are in complete control of a device’s firmware: they can choose to take advantage of these enhancements, or not. However, Kinibi’s cryptographic library is provided a part of a device’s firmware, which leaves TAP SDK developers with an uncomfortable choice. Either they can write for the lowest common denominator, settling for old algorithms and lower performance; or they can play with all the new toys and shut themselves off from running on the many devices which have only 310A, or even 302A, installed.

For this reason, Trustonic has added a new library, named GpTRIC, to our SDK, with the aim of providing a rich, consistent, efficient, and secure cryptographic API to TAP developers, without being held back by old firmware versions.

GpTRIC is a partial implementation of the GlobalPlatform TEE Internal API. It intercepts most of the Trusted Storage, and Cryptographic Operations API functions looking for important types and algorithms that it understands, and when it finds one it takes the necessary action using its built-in cryptographic library. Function calls it doesn’t understand are passed on to the GlobalPlatform API implementation in the device’s firmware.

One less apparent difficulty is that GpTRIC can’t directly use the underlying platform’s secure object storage for its key data. There are several reasons for this: for one thing, Kinibi will refuse to store key data it doesn’t understand, which rules out elliptic curve keys before Kinibi 400A; for another, it won’t let GpTRIC read back key data not marked as ‘extractable’, which means that GpTRIC wouldn’t be able to use the key data with its more modern crypto implementation. So, rather than trying to store its key data as key data, GpTRIC instead stores it in a persistent object’s data stream, with a distinctive marker to prevent it from being confused with user data. We call the part of the data stream which stores key data the GpTRIC intrusion.

I suppose one might ask why we didn’t decide to smuggle GpTRIC’s key data into the key-storage part of the underlying persistent object, say as a generic-secret, or even as a rather strange RSA key. The answer is that, firstly, there isn’t enough space for a 4096-bit RSA private key in a maximally sized generic-secret object, and that older Kinibi versions can’t cope with keys larger than 2048 bits (which might be possible with some compression scheme). Secondly, GpTRIC needs somewhere to maintain the object’s usage permission bits, which, unlike the key data attributes, are mutable, and it can’t use the underlying permission bits because clearing the ‘extractable’ bit would lock GpTRIC out of its key data.

Like ordinary platform keys, GpTRIC keys can be provisioned securely per device, without having to embed class keys in TA binaries or, indeed, anywhere else; and this allows provisioning of any key type that GpTRIC can understand, rather than being limited to the target device’s built-in repertoire. All that’s necessary to achieve this is for the TAMv2 server to transmit an object with a correctly formatted GpTRIC intrusion containing the necessary key data. Once this is stored in the Secure File System, GpTRIC will notice the intrusion and allow the TA to use the keys in the usual fashion.

GpTRIC is still a reasonably young library, and it still has some rough edges which we’re working on filing off. Also, we’ve not stopped with the low-level cryptographic improvements either: GpTRIC is much faster at RSA, elliptic curve crypto, and AES-GCM than any released Kinibi, and offers significantly improved resistance to microarchitectural side-channel attacks. As we implement new algorithms and improve our implementations of existing ones, GpTRIC will make sure that SP developers can make use of these advances early, and across a broad selection of devices.

Technical articles