STS RSFN MULTIPLATFORM

One of the most sensitive parts of the solutions provided by Prodist is the private key service, which falls roughly under concepts such as cryptographic module (as in hardware cryptographic module, HSM) or key management system (KMS).

The idea that unites these concepts is that of private key isolation, i.e. the idea of a security perimeter within which private keys are enclosed, and outside of which they never escape.

The private key service does not provide copies of the private keys it holds, but rather performs cryptographic operations with these keys on behalf of the application.

Several solutions provided by Prodist include the Prodist STS, which also has the function of a private key service, designed in 2002 to specifically serve messaging services of the new Brazilian Payment System, and extended in 2019 with sufficient capabilities to serve messaging services of the recent Instant Payment System.

The private key server program itself, the STS server program, was born tied to the Microsoft Windows operating system and remains so today. In 2024, Prodist will evolve into STS Multiplatform, a suite of basic services untethered from the operating system, approved for production on Microsoft Windows and Red Hat Enterprise Linux (or equivalent).

In order to provide multiplatform solutions, Prodist has designed and is now building the new pieces that will underpin the new architecture, which are roughly three: the secrets vault, the private key service and the certificate service.

Secrets in general, and private keys in particular, must be controlled with extreme care to ensure the desired security properties, such as the non-repudiation of digital signatures. Specialized solutions, such as hardware security modules (HSM), offer extremely high levels of isolation,
with properties such as anti-tampering. However, these solutions are expensive to purchase and maintain.

Even when HSMs are available to store keys, there are always secrets to store locally, e.g. the HSM's own PIN.

The first piece built by Prodist for the new multiplatform architecture is the secrets vault, called Prodist Vault.

The first-generation Prodist Vault has been present in STS since the beginning to store passwords, including HSM access PINs and PFX file passwords (a.k.a. PKCS #12). Its implementation is strongly tied to Microsoft Windows.

The second-generation Prodist Vault will store name/value records in a portable, multi-platform file. Each record will be guaranteed confidentiality and authenticity by authenticated encryption with associated data (AEAD) with a 256-bit symmetric key.

Each Prodist Vault will in turn be protected by a master key provided by and under the control of the application. The new master key architecture allows the application to use keys stored in a file, keys accessed via the CryptoKI provider (e.g. HSM) and keys stored via the NCrypt provider (from Microsoft
Windows).

Private key services differ from secret services in general in that they aim to isolate private keys, i.e. to ensure that private keys are never copied outside their security perimeter.

These services must operate with the private keys on behalf of the applications, i.e. they must provide an interface with the cryptographic operations that the application needs and a means for the application to make use of these operations.

The original Prodist STS provides operations via a proprietary protocol which, for historical reasons, is strongly tied to the concepts and requirements of the Brazilian Payment System.

The original protocol is difficult to implement and is only available for DCOM (Microsoft Windows) and Java programming languages / environments.

The original service allows you to consult and operate with keys stored in the first-generation Prodist Vault or with keys accessed via the CryptoKI driver (e.g. from an HSM).

The new private key service, which will be part of the new multi-platform architecture, will provide a new proprietary protocol, based on HTTP/2, designed in advance to cover a wide range of applications, such as the digital signing of Ethereum smart contracts, without losing capacity in the applications currently
in production.

The new protocol will be malleable enough to allow "client" modules in a wide range of programming languages / environments, including C, C++, Java, C#, Python and others.

The new service will make it possible to consult and operate with keys stored in the second-generation Prodist Vault, with keys accessed via the CryptoKI driver (e.g. from an HSM) or with keys accessed via the NCrypt provider (from Microsoft Windows).

Prodist visualizes architectures with private keys in Prodist Vault vaults protected by a master key on the TPM chip, guaranteeing a high level of access control.

Public key certificates, unlike private keys, are information with the express purpose of being widely disseminated among all participants in a network, requiring no secrecy in either their communication or their storage.

Public key certificate services are services that specialize in querying this specific type of information.

The original Prodist STS provides operations via a proprietary protocol which, for historical reasons, is strongly tied to the concepts and requirements of the Brazilian Payment System.

The original protocol is difficult to implement and is only available for DCOM (Microsoft Windows) and Java programming languages / environments.

The original service allows you to consult locally stored certificates only.

The new public key certificate service, which will be part of the new multi-platform architecture, will provide a new proprietary protocol, based on HTTP/2, designed in advance to cover a wide range of applications, such as the digital signing of applications (e.g. Android or iOS), without losing capacity in the
applications currently in production.

The new protocol will be malleable enough to allow "client" modules in a wide range of programming languages / environments, including C, C++, Java, C#, Python and others.

The new service, which will be part of the new multiplatform architecture, will make it possible to consult certificates stored locally or accessed via the ODBC / JDBC driver (e.g. in a relational database).

Prodist visualizes architectures with public key certificates in a database, allowing atomic and distributed "activation" during renewal procedures.

In this example, we'll describe an architecture with a messaging application carrying signed XML messages, written in Java to run on the JVM, integrated with public key and private key certificate services, both running on a single server, with data stored locally in a Prodist Vault.

The diagram below shows how the application is assembled. The dummy module Prodist xmldsig-api is in the position of one of the domain modules supplied by Prodist, such as Prodist pix-spi-api.

This dummy module applies the JDK to sign XML messages and send these messages to some recipient over a secure TLS channel. In the JDK, encryption services are provided by the Java Cryptography Architecture, JCA, an architecture based on service providers. The Prodist jca-provider module connects the JCA to the private key and public key certificate services.

In the diagram below, we can see the architecture, which is made up of two "environments", the application on the left and the "services" on the right, representing the fact that they are isolated from each other. Private keys and public key certificates are stored locally in the "services" environment, and the private keys are stored in a Prodist Vault.

In this example, we describe a variation of the previous architecture, with the private keys stored in the HSM and the public key certificates stored in a relational database. The service environment still has a Prodist Vault to store the HSM PIN.

In this example, we describe a variation of the previous architecture, with the "services" environment separated into three independent environments, "keys 1", "keys 2" and "certificates". In this architecture, encryption operations are distributed with load balancing and fault tolerance. We have omitted the storage options
previously exemplified.