In essence, the SkyTrust system represents a virtual smartcard that can be accessed over the Internet from arbitrary devices and platforms. The private keys are stored in a secure environment (e.g., a Hardware Security Module) of the server and – similar to a smartcard – cannot be exported by the user. Also similar to a smartcard, the SkyTrust server exposes a cryptographic API for executing signing/decrypting operations. This API can be accessed via a REST interface that requires strong authentication mechanisms to protect the cryptographic functions involving the keys.

Main Advantages

The main features and advantages or the SkyTrust architecture are

  • Available on arbitrary platforms: Current solutions, such as smartcards, NFC-based security tokens, Trusted Platform Modules, or integrated Secure Elements securely store cryptographic keys, which are used by applications calling exposed cryptographic functions. Although those components allow the secure handling of cryptographic keys, they come with a wide range of problems related to key distribution, platform independence and usability. Project SkyTrust aims to solve these problems be keeping the keys in a secure environment at a central location. Similar to the APIs used to access the cryptographic functions of the aforementioned devices, SkyTrust servers expose an API that can be accessed over the Internet by using strong authentication. Since the SkyTrust API is based on a simple JSON based protocol that is exposed via a REST API, the SkyTrust architecture can be used by any device/platform that is capable of connecting to the Internet.
  • Solving the key distribution problem: By removing the need for a local component that stores the cryptographic keys (e.g., smartcard, NFC security token) the key distribution problem is not relevant anymore. Whenever a key needs to made available for the user, the user can either add this key by himself to the SkyTrust infrastructure, or leave this work to a central administrator (e.g. for use cases in companies). Since, there is no need to transfer the key material to the user and thus store the keys in a local secure storage area, there is no key distribution process involved. This also means that the users can execute cryptographic functions involving their keys from arbitrary devices without any additional hardware components or the requirement to export/import/handle key material.


The SkyTrust system is based on various components that expose the cryptographic functions to the respective end user devices. The main components are:

  • Receivers: A receiver is a communication interface that consumes SkyTrust related protocol messages and hands them over to the routing protocol implemented in the SkyTrust element. A simple example for a receiver is an HTTP web server, that provides a REST interface to consume SkyTrust related protocol messages.
  • Actors: An actor is a component that is capable of handling SkyTrust related protocol messages. A good example for an actor would be a cryptographic library that consumes the SkyTrust specific protocol commands for, e.g., signing or decrypting, and uses the centrally stored key material to execute the commands. The actor of the demo system is a Java-based JCE provider that communicates with an underlying HSM via PKCS11. In the typical scenario an actor has access to cryptographic keys required for the respective cryptographic operations. However, this is not a requirement since an actor could also provide other functionality that is not available at the client and thus needs to be executed on the SkyTrust server. A good example would be a high-level CMS library that is capable of encrypting S/MIME messages. Such an actor would not require any private cryptographic keys, since the encryption operation could be carried out by using user-supplied certificates that are transmitted over the SkyTrust protocol.
    SkyTrust Element: A SkyTrust element contains multiple receivers and actors (at least one per category). The core component of the SkyTrust element is a router component, that forwards received command messages to the respective actors or forwards them to other SkyTrust elements, if the requested operation cannot be carried out locally.
  • Other components: In order to provide authentication mechanisms, manage user sessions and enforce access rights, the gatekeeper component is used by actors to check the validity of incoming SkyTrust requests. Furthermore, authentication plugins might also be implemented within a SkyTrust element, which allows local application to execute authentication requests (e.g. oAuth authentication or user name/passwords).