In a secure network, certificates play a crucial role by enabling the establishment of secure connections using TLS. They also ensure the authenticity and integrity of published data.
Both the Sending System and Receiving System expose endpoints that must be protected from unauthorized and malicious interactions. More specifically, access control measures must be applied to the following endpoints:
-
Receiving System:
-
Sending System: Mutual TLS shall be used to protect these endpoints in the following ways:
-
Authentication: The sending and receiving system are mutually verifying each other's identity before establishing a secure connection. In this way only systems that are trusted (are a GtK) are allowed to set up connections.
-
Encryption: an mTLS connection is encrypted. This means that only the sending and receiving systems can read the exchanged data and no third, unauthorized party can ‘listen in’.
-
Integrity: mTLS assures that the data has not been modified by any unauthorized party during transmission. Any tampering attempts would alerting the recipient.
-
Protection against replay attacks: Each message sent over the connection includes a sequence number, and the recipient keeps track of the sequence numbers it has received. If a message with a previously received sequence number arrives, it is considered a replayed message and is rejected. This prevents attackers from intercepting and resending previously valid messages.
· For node authentication TLS inactivity timeout settings should be set as low as possible but in accordance with the HTTP timeout values set in the HIE infrastructure. Note that in case of a DICOM exchange use case a minimum HTTP timeout value of 10 minutes is defined as “normal” (chapter 4.2). The TLS inactivity timeout settings shall be aligned with the XCA-I HTTP timeout values when (large) DICOM studies are retrieved.
· The SubjectDN/CN of a system certificate shall match the system's public host name.
Terminology
-
Certificate Authority (CA): A trusted entity responsible for issuing and managing certificates used in secure network connections.
-
Certificate Revocation List (CRL): A list maintained by a Certificate Authority, containing revoked certificates to prevent the use of compromised or invalid certificates.
-
Public Key Infrastructure overheid (PKIo): A PKI structure controlled by the Dutch government, governing the issuance and management of certificates in the Netherlands.
-
Trusted Service Provider (TSP): A party authorized to issue PKIo certificates within the PKIo infrastructure, ensuring the integrity and security of the certificates they issue.
Network level security: mTLS 1.3
On network level mutual TLS (mTLS) must be applied. The TLS-implementation must comply with the security level “Good” as specified by the National Cyber Security Centre (NCSC). At the time of writing, the
IT Security Guidelines for Transport Layer Security (TLS) require version 1.3 of the TLS standard for the security level “Good”. In the case one or more of the algorithms are declassified by NCSC will this be described in a new version of Twiin.
Communication between GtK’s is SOAP over mTLS for transport and WS-Security with SAML for application security. The last is based on the IHE XUA profile (see chapter 4.5)
CRL / OCSP / CPS
The validity of a certificate shall be verified using a CRL, OCSP, or CPS check. A determined validity may be relied upon for a maximum of one hour, after which the verification must be performed again. If the validity of a certificate cannot be established, the connection shall be terminated, as it shall also be terminated if the certificate is found to be invalid.
PKIoverheid
Both the client and server certificates must be PKIo-certificates that are issued under the CA “Staat der Nederlanden Private Services CA – G1” (this includes UZI server certificates issued by UZI-registry (CIBG)). https://cert.pkioverheid.nl/