V-OS is the world’s first virtual secure element.
This is something we at V-Key take great pride in. It is also a claim we dare to make, based on the innovation that has gone into virtualizing the hardware tamper-proof protection, the secure cryptographic environment, role separation between manufacturer, issuer, application developers.
Cryptography plays a dual-role in these; to secure and manage the secrets kept within V-OS, and to provide a lightweight yet comprehensive cryptographic library.
We’ve assembled and built a diverse toolbox of cryptographic primitives, that are chosen to meet modern requirements and international standards, including FIPS 140-2 Level 3. These pieces are welded together to achieve the goals of virtualizing the hardware secure element and building a cryptographic library, guided by a deep understanding of the characteristics of these building blocks. Running through all these is a consistent design approach to achieve security, functionality and flexibility in our security solution, in line with cryptographic best practices.
Software is the new Hardware
Traditionally, hardware is the go-to solution for high security, and for good reasons too. Hardware requires physical access, and thus interactions with the hardware module can be funneled through the limited interfaces. Controls placed at these interfaces then effectively safeguards the rest of the hardware. Tampering of the hardware itself is prohibited by detection of the activity and responding to it accordingly, usually by wiping all sensitive data.
Memory separation on the hardware can take place in the form of distinct memory locations that have no direct physical connection to each other. Reading and writing to these can be restricted by physical access. The same natural characteristics that makes hardware secure also makes it costly and inflexible. It can achieve limited functions very securely, but it cannot be repurposed easily.
On the mobile device, there is often a hardware secure element present, the SIM card. The access to this however, is limited to the mobile service provider and very expensive to deploy. Apple recently introduced a second secure element on their phones, to improve the security of their apps and those of their partners. Still, tight controls around the access to this security feature remain, meaning that a secure element backed security solution is not available to third party app developers, who may need higher security for their mobile apps. In addition, accessible hardware secure elements are not ubiquitous across mobile operating systems and their respective phones, and may not be implemented in the same way, severely limiting this avenue for mobile use cases which require enhanced security.
By virtualizing the secure element, V-OS fills this gap; providing a secure environment to store data as well as execute instructions on this sensitive information, while maintaining the low-cost, flexible nature of software. By supporting both major mobile operating systems, V-OS allows mass market implementation of highly secure mission critical applications.
Virtualizing the Secure Element
V-OS is a virtual machine solution, with executable virtual machine code compiled into an obfuscated binary, referred to as firmware, and a protected processor to perform its execution. There is the kernel firmware, which acts as the operating system interacting with the processor to manage the mobile security controls and privileged functions. There is also application firmware, referred to as trusted applications (TA), which are secure functionalities running within V-OS to support the specific functions needed by the mobile app. Besides the mandatory execution of the kernel, V-OS may execute one or more TAs concurrently. Contents of the firmware, both data and instructions, are protected by our proprietary solutions to prevent unauthorized use and retrieval of it.
The kernel firmware is signed by V-Key’s manufacturer private key, providing the mark of authenticity. The processor, which is also built by the manufacturer, maintains the corresponding certificate with which to verify the signature. This ensures that only a V-Key-built kernel firmware will be executed. Likewise, the trusted application firmware is signed by TA developer’s private key, with the corresponding certificate used by the kernel to verify the signature. This ensures that only valid TAs can be executed within V-OS.
The provisioning process of the virtual secure element involves familiar roles: the manufacturer V-Key, the issuer-customer, and the application developer and both customer and third-party developers.
During firmware generation by the manufacturer for the specified issuer-customer, the firmware is built and preloaded with its own unique set of firmware keys, one of which acts as the firmware’s root key, and another the initial supplier key. The firmware’s root key is used to derive further firmware keys that are then used to encrypt and sign firmware data, or to derive additional downstream keys to support the secure storage functionalities. The initial supplier key, like its secure element counterpart, is used to allow the issuer to load its own keys.
The build of the kernel firmware and processor takes place within the secure environs of a hardware security module (HSM), which is used to store the customer’s master keys, provide high-quality entropy for secure randomization, as well as provide the secure execution of customized HSM code for processing cryptographic data for the firmware and processor builds. The application firmware is usually built on the customer’s premises, for distinct role separation, and convenience of deployment by customer.
The trusted applications can be further individualized by the customer, with every TA firmware distributed to the customer containing a unique set of firmware keys. This guards against a rogue end user trying to recover application secrets, as he can only recover the keys specific to his own device and end-user account.
Within the Kernel
To bind the mobile application with the kernel firmware, parameters of the mobile application are transcribed within a kernel license file, which can only be read by the kernel using its license key. The license file is generated alongside the kernel firmware and processor, and is specific to the kernel firmware. The license key is derived from the firmware’s root key during the generation process, never leaving the secure execution environment of the HSM. Without the appropriate license file for the kernel and mobile app, that uses the same license key and has matching mobile app details, V-OS will refuse to execute.
The license file also contains a TA user license private key, which will be installed into the kernel on the first start. Subsequently, this private key is used in a challenge-response protocol with the application developer’s TA or server to verify that this kernel has the appropriate license to utilize the TA. Together with the verification of the TA firmware’s signature, the kernel and TA accomplish mutual authentication.
This illustrates the use of a cryptographic key, the firmware-bound license key, to enforce the relationship between mobile app and the virtual secure element. Only authorized mobile apps can leverage the virtual secure element for additional security. In addition, unlike the hardware secure element, multiple V-OS virtual secure elements can exist within the same device. Each mobile app will operate its own V-OS, and retain exclusive access to their own virtual secure element.
A hardware secure element does not leave the device. Neither should a virtual secure element. V-OS collates device specific information, without collecting information about the end-user, and translates it into a unique confidential device fingerprint, abbreviated as DFP. This fingerprint is forged with the kernel firmware’s root key and a locally-generated random secret to form a storage root key (SRK).
Trusted Storage
A primary function of a secure element is to provide secure, persistent storage of confidential information, be it long term secret keys or end-users’ data. To support the loading of multiple apps within the same secure element, memory isolation between apps must be enforced.
In V-OS, the trusted storage spaces are persistent repositories that are accessed by a single unique storage key. By means of authenticated encryption, these trusted storage spaces contain authenticated data, or confidential-and-authenticated data within the repository. The choice of storage key, control of the storage’s access can be defined.
The trusted storage spaces are organized in a tree hierarchy. At the base, the trusted storage keystore is protected by the SRK, making it a device-bound and kernel-bound repository. If the trusted storage keystore’s protected contents are moved to a different device or loaded with a different kernel, the derived SRK is no longer the same, and thus the contents cannot be retrieved.
What are the contents of this keystore? The trusted storage keystore functions as a keychain; it holds the storage keys for the next tier of trusted storage spaces, which are accessible only by the individual trusted apps and kernel. This mechanism enforces the memory separation between the individual apps’ confidential data, emulating the memory isolation in hardware secure elements.
The TA’s storage keys themselves can be configured by the TA developer, either as a random key generated on the device, or password-based keys that can be persisted or derived just prior to use. The passwords can be replaced with biometric credentials. This flexibility allows the developer to decide the desired use case for their application.
With random storage keys, the locally-generated secret and the DFP, there is secret knowledge not available to the manufacturer and the issuer, thus keeping the end-user’s secrets confidential. The option of passwords or biometric credentials extends the distinction further with something that only the end-user knows, or is.
Interface for V-OS
V-OS provides a comprehensive cryptographic library, for symmetric ciphers, stream ciphers, hash functions and its derivatives, random number generation, and public key cryptography. TA developers can call C functions in the provided firmware libraries from the Trusted Application Software Development Kit (TA SDK).
In the absence of a TA, V-OS provides a corresponding suite of APIs in C/C++, Java (for Android), and Objective-C (for iOS), termed VosWrapper, which allows for the mobile app developer to access the cryptographic functions. As a native developer is accessing the secure element from a less secure environment, the APIs available are reduced, for example to remove the option of retrieving a secret key in plain from the secure element.
The cryptographic functions supported include:
The suite also provides keystore, certstore and datastore functions, which are designed as trusted storage spaces on top of the underlying trusted storage hierarchy. This allows the natural inheritance of the device and firmware binding as well as option for passwords and biometrics usage.
V-OS has attained FIPS 140-2 Level 1 Certification in 2016 (Cert #2706). We’ve since enhanced our cryptographic suite, by adding ECC and authenticated encryption amongst others, and deepened the support for handling of certificates and key management.
This set of functionalities are developed with the aim of tackling the security needs of a mobile app developer, with minimal to no modifications needed. Keys can be generated within V-OS, and used for operations on native messages and data, all without the keys leaving V-OS. Public key pairs can be generated within V-OS, exporting the public key as a certificate and used to sign or decrypt messages. Certificates can be imported into V-OS and used for verification of signatures or encrypting data.
Cryptographic Design
We’ve looked at the use of cryptography to define a virtual secure element, and making cryptographic and storage functionalities available for mobile app developers. How does V-Key decide how to deploy cryptography in V-OS to achieve its security goals?
The cryptographic toolbox that we have is simply a collection of ‘components’ we can use to solve our cryptographic and security problems, and thus we begin with defining the problem setting that we face.
Which are the entities involved? The possible solutions can vary greatly based on the parties in play. Between the license file and the firmware, which share a common generation location, there is a natural pre-shared key, the kernel firmware’s root key, that can be used to derive the common key. Between V-Key’s HSM and a customer’s server, without a trusted courier, we would have to rely on public key cryptosystem to perform key establishment.
What are we trying to achieve? Confidentiality, integrity, or authenticity/authorization? Encryption is needed for confidentiality, and hashing for checksum allows for integrity checking. Authenticity can be achieved with a message authentication code (MAC) or signing (private key encryption) while authorization may be permitted after authentication or via the provisioning of a password.
What is the expected traffic, or how frequently will this key be used? Most attacks on cryptography require the collection of a large volume of ciphertexts or plaintext-ciphertext pairs. Hence the rule-of-thumb is that the lifespan of a key relates inversely to its usage. If a key is expected to be used frequently, or used to encrypt a large volume of data, then a mechanism is needed to refresh this key. For example, the key used to encrypt a single TLS session is generated and used only for that session, while the RSA or ECC key pair can be used across multiple sessions, usually for years.
Besides the validity period, there are also other details around the lifecycle of each key to consider:
1. Entity performing generation
2. Storage-at-rest before distribution
3. Mode of distribution
4. Storage-at-rest before usage
5. Secure usage
6. Validity
7. Key Destruction
We also impose additional constraints on our solutions:
- Each key that is defined for a solution should be used only with a single algorithm. If it is a symmetric key, i.e. both parties have the same information about the key, then it should ideally be known only by the two parties.
- Each key should only have a single clearly defined purpose. A 256-bit AES-CBC key within a kernel firmware used for communicating with a server should not be used to protect its own data. This confusion of a key’s purpose makes defining the key’s lifecycle difficult.
- The entity that is a key’s custodian should be clearly defined. The notion of a client is ambiguous, as V-OS is a more secure environment that the native environment, even though they are both part of a client.
These design principles help us maintain a clean separation of roles, and the knowledge of cryptographic secrets that each of them hold, with the key custodianship lying with only the entities that should have it. This makes authentication meaningful, as authentication relies on the proof of knowledge of a secret.
This is but a glimpse into the importance cryptography plays in V-Key, limited only to the design of V-OS as a virtual secure element, and the design philosophy that goes into choice of solutions.
