Crypto-material Management
This article describes how DirX Access uses cryptography. It is intended to provide DirX Access administrators with insight into the cryptography-dependent mechanisms and to enable them to verify the overall security of their specific deployment. The goal of this presentation is to provide a fast and easy way to get answers to cryptography questions, whether from the perspective of each particular keystore or a specific feature.
Security Architecture
This section describes the DirX Access security architecture and its operation within DirX Access. The overall architecture of DirX Access can be divided into multiple layers.
A persistence layer is represented by the Application and User Repositories and DirX Access Cache Servers providing data to a layer of DirX Access Servers. DirX Access Servers can communicate to internal client components such as the PEPs and to external components in the internet. Optionally, additional layer can be represented by DirX Access Bridge.
The concept behind the layered architecture is simple: to enable the application of different security measures on different layers; specifically, to deploy the server layer in a secure intranet environment and the client’s part in the demilitarized zone (DMZ).
The next sections describe the security specifics of the environments in which the DirX Access system components operate along with the recommended measures to apply.
Application Repository
The Application Repository must be deployed in a highly-protected environment solely under the control of the administrator. We recommend limiting the access to the machine just to the ports that communicate with the Services containers.
What can a breach mean?
-
Altering configuration data - an attacker is able to influence a run-time system functionality (for example, authentication and authorization policies).
-
Cryptomaterial theft - an attacker is able to retrieve the cryptographic keys and leverage them.
-
Private data theft - in specific use cases, the Application Repository may contain users’ private data. As a result, the configuration must enable the use of risk-based authentication, FIDO authentication, or OTP authentication.
-
User impersonation - the OTP data stored in the Application Repository might be leveraged by an attacker to impersonate a corresponding system user for the validity interval of the OTP data.
What doesn’t a breach mean?
-
Getting into a User repository - the Application Repository does not contain any credentials for the User Repository.
-
Stealing FIDO private credentials – a theft of FIDO credentials from the Application Repository does not lead to any possibility of impersonation of any user by an attacker.
User Repository
The User Repository is a component to be deployed in a highly-protected environment solely under the control of the administrator. We recommend limiting the access to the machine just to the ports communicating with the Services containers. The User Repository serves to DirX Access only as a source of user information and is not managed by it (contrary to the Application Repository). Hence, from the perspective of DirX Access, we cannot really predict what is contained within it. Typically, however, a breach means a private data and credentials theft.
DirX Access Cache Server
The DirX Access Cache Server is a component containing both persisted and short-lived data. It doesn’t contain the SSO sessions per se, however, may contain federation tokens and intermediary protocol messages.
What can a breach mean?
-
Refresh token theft - an attacker with access to refresh token cache/persistence can read the entries and use them in their environment
-
Private data theft - the caches contain user-related (potentially private) data
What doesn’t a breach mean?
-
Altering configuration data - there’s no configuration data stored in the DirX Access Cache Server
-
Ability to create a new SSO session - no material enabling creation of new session is in the DirX Access Cache Server
DirX Access Server
The Services container is a component to be deployed in a highly-protected environment solely under the control of the administrator. We recommend limiting the access to the machine just to the ports communicating with the internal clients and repositories. This configuration may, however, mean that the standard HTTP(S) ports are open; in this case, an additional protection can be applied by limiting the access to the ports on the intranet.
In some use cases, the ports must be accessible to third-party clients residing outside the intranet (for example, via SOAP and RESTful WebServices). Note that DirX Access ensures protection against malicious content of the communication (for example, protection against malicious code injection). However, external means should be used to protect the connection itself against attacks, e.g. DoS.
What can a breach mean?
-
Repository credentials theft - the instance file system directory contains the repositories credentials. Access to it means the credentials could be stolen.
-
Cryptomaterial theft - if not accessed directly in the Application Repository, the Services Container is able to download all the cryptographic material, which can be then exposed to the attacker.
-
Altering the run-time system behavior - there are multiple ways of influencing it.
PEP
The PEP is a component to be deployed in a demilitarized zone. Furthermore, it might be deployed in a container that is not under DirX Access control but still must be under the control of the system administrator.
What does a breach mean?
-
Privileged access to the services - the client component provides a privileged access to the Services container and can in this way alter the run-time system behavior.
-
Cryptomaterial theft
-
The instance file system directory contains the client-side secure communication keystore.
-
The privileged role may be leveraged to download the features keystores.
-
DirX Access Crypto Containers
Any cryptomaterial used in the Services Container is referenced through Crypto Container configuration in the Application Repository. The configuration references the Keystore configuration and describes the intended usage. DirX Access does not have extra Keystore configuration types to differentiate whether the actual usage is for secure communication between its components or external purposes (DirX Access features).
The description of the intended usage is given by entries referencing the cryptographic material within the referenced keystore.
Each entry corresponds to the cryptomaterial entry within the referenced keystore and is described via type, alias, password, algorithm,
validity and paired alias as a counterpart entry within the same keystore, e.g. paired alias of a certificate entry to a private key entry.
Please see
Administrative
Tasks for more information about Crypto Container and Keystore configuration types.
TODO: key rotation
Use Cases
Establishing the internal client SSL/TLC context
The communication is performed via the REST Web Service endpoints that are explicitly appointed to serve for the communication with the DirX Access internal clients. These endpoints are by default protected by the keystores that shouldn’t be used for any other purpose, and especially shouldn’t be transferred to any third party.
TODO