Presentation of cryptographic processes

Date

Apr 24, 2024

Written by

Hubert TOUVET, Vincent Cardon

Applicable for WAPT

>= 2.3.0.13180

Version of the Document

2.3.0.0-0

Git hash

7e46aa8617c72228976f383be2e9d2f70c3cc7bd

WAPT solution components and cryptographic mechanism specification

Cryptographic processes are involved in the following activities:

  • Signature and verification of files contained in a package.

  • Signature and verification of package attributes.

  • Signature and verification of immediate actions on WAPT clients.

  • Signature of inventories and WAPT customer status.

  • Websockets connection authentication for WAPT clients on the WAPT Server.

  • HTTPS communication between WAPT clients and the WAPT Server.

  • HTTPS communications between the WAPT Console and the WAPT Server.

  • HTTPS communications between WAPT clients and WAPT repositories.

Software component versions are specified in the “List of third-party components integrated into the product (COTS)” section of the Security Target.

WAPT Server cryptographic specifications

The WAPT Server runs on a PostgreSQL database.

Nginx service

The Nginx Server serves packages to client workstations and acts as a reverse proxy for the WAPT Server. It is configured in TLS v1.3 with the EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH ciphers.

Nginx service cryptographic specifications

Crypto hardware used

Usage

Specifications

Location

Creation / renewal

nginx https Server private key

Connections Console WAPT- Server

Connections Agent WAPT - Server

RSA 2048 bits.

Unencrypted PEM format.

/opt/wapt/waptserver/ssl/key.pem

Initial Server post-configuration

nginx https Server certificate

Server authentication

Encrypt https connections.

X509 certificate with RSA key

PEM format

Duration 3 years

/opt/wapt/waptserver/ssl/cert.pem

Initial Server post-configuration

When renewing, it is necessary to distribute the new https Server certificate to the Agents with a WAPT package before the previous one expires.

Diffie-Hellman key

Initial key exchange

2048 bits

PEM format.

/etc/ssl/certs/dhparam.pem

Initial Server post-configuration

https client CA

Client certificate authentication for https connections to WAPT Agents and the WAPT Console.

An X509 format certificate Store containing copies of the CA PKI WAPT Agents and CA PKI WAPT Administrators

Defined in /opt/wapt/conf/waptserver.ini by the key ssl_client_certificates in the [options] section.

Initial Server post-configuration and updated manually each time the CA PKI WAPT Agents and CA PKI WAPT Administrators

Clients https CRL

Enables NGINX to check that client certificates have not been revoked.

A file in PEM format containing copies of the PKI Agents WAPT and CRL PKI WAPT administrators

Defined in /opt/wapt/conf/waptserver.ini by the key ssl_client_crls in the [options] section.

CRL Store updated every hour by a scheduled task on the WAPT Server.

The clients_signing_crl CRL and the *.crt files in PEM format in the directory defined by ssl_additional_crls are concatenated for use by NGINX.

Keytab kerberos

Authentication of WAPT Console logins.

Authentication of WAPT Agent initial registrations.

SPN: HTTP/<fqdn of WAPT Server> @<REALM>

/etc/nginx/http-krb5.keytab

Keytab created and extracted from AD manually.

No automatic renewal.

WAPT Server service

For WAPT Agents, the WAPT Serveur service:

  • Manages the authorization and initial registration of WAPT Agents and signs WAPT Agent CSR .

  • Checks the authenticity and integrity of status information sent by WAPT Agents.

  • Authorizes Websockets connections.

For the WAPT Console, the WAPT:

  • Manages WAPT Administrator authentication and access authorizations to data returned by WAPT Agents.

Cryptographic specifications for the WAPT service

Crypto hardware used

Usage

Specifications

Location

Creation / renewal

PKI private key WAPT Agents.

Signs Agent CSR on initial registration and CSR for temporary client certificates for Console https access.

RSA 2048 bits.

Unencrypted PEM format.

Defined in /opt/wapt/conf/waptserver.ini by the key clients_signing_key in the [options] section.

Default: /opt/wapt/conf/ca-<servername>.pem.

Initialized during WAPT Server installation (postconf).

CA PKI Agents WAPT.

Certificate with which Agent certificates can be verified.

This certificate is used by nginx for Agent client certificate authentication.

Self-signed and pinned X509 certificatewith RSA key.

PEM format.

Duration 3 years.

Defined in /opt/wapt/conf/waptserver.ini by key clients_signing_certificate in the [options] section.

Default: /opt/wapt/conf/ca-<servername>.crt.

Initialized during WAPT Server installation (postconf).

CA PKI WAPT Administrators.

Certificates used to verify WAPT administrator certificates.

This certificate is used by waptserver to authorize packages to be sent to the Server.

CertificatesX509 with RSA key.

PEM format.

Organization-specific specifications.

Defined in /opt/wapt/conf/waptserver.ini by key trusted_signers_certificates_folder in the [options] section.

Provided and managed by the organization.

CRL PKI WAPT Agents.

Stores serial numbers of banned WAPT Agent certificates.

PEM format.

Duration 10 days.

Defined in /opt/wapt/conf/waptserver.ini by key clients_signing_crl in the [options] section.

Default: /var/www/ssl/ca-<servername>.crt.

Initialized at post-configuration.

Fed and re-signed each time a WAPT Agent is deleted.

Automatic task that periodically re-signs the CRL.

Known certificates.

Enables WAPT Console and WAPT Agents to reconstitute certificate chains (in the case of intermediate CA).

Defined in /opt/wapt/conf/waptserver.ini by key known_certificates_folder in the [options] section.

Default: /var/www/html/wapt/ssl/*.crt.

Certificates are automatically extracted from packages when they are sent to the Server.

Certificates associated with administrators are also extracted when user accounts are registered.

Secret admin account.

For initial authentication of the WAPT Console for the account designated wapt_user.

Minimum password length: 20 characters.

Verified complexity.

PBKDF2 password derivation with 29000 iterations, hmac-sha256.

Defined in /opt/wapt/conf/waptserver.ini by key wapt_password in the [options] section.

Initialized during installation.

Can be changed from the WAPT Console by a WAPT administrator authenticated with the same account.

Secret session cookies.

Authenticates WAPT Server API calls after correct login.

64 ascii characters.

Defined in /opt/wapt/conf/waptserver.ini by key secret_key in the [options] section.

Set to a random value on initial installation.

Not automatically renewed.

Token encryption secret.

Authenticates Agent Websockets connections (deprecated behavior, disabled in TOE configuration).

Authenticates the login for the “Waptselfservice” application.

Tokens are generated during Server login if the Server configuration authorizes the “token” method, or if the login call explicitly specifies that it wants a token instead of a session cookie.

64 ascii characters.

Defined in /opt/wapt/conf/waptserver.ini by key token_secret_key in the [options] section.

Set to a random value on initial installation.

Not automatically renewed.

WAPT Agent certificates.

Authentication and integrity checking of data sent by WAPT Agents.

Authentication of websocket token requests by WAPT Agents (deprecated behavior, disabled in TOE configuration).

X509 certificate signed by CA PKI WAPT Agents.

PEM format.

Default duration 3 years.

Extended Key Usage: TLS Web Client Authentication.

Key Usage: Digital Signature.

Field ‘host_certificate’ Table ‘Hosts’ in the ‘wapt’ database.

WAPT Administrator Certificates.

Lists directors’ personal certificates.

X509 certificate signed by the CA.

PEM format.

Default Duration 3 years.

Extended Key Usage: TLS Web Client Authentication.

Key Usage: Digital Signature.

Field user_certificate, Table ‘WaptUsers’ from the ‘wapt’ database.

Created from the WAPT Console.

Assigned to a WAPT Administrator accountWAPT Console’s “WAPT user and rights management” function.

Certificate fingerprints WAPT Administrator.

Authorization to access WAPT Server API after successful authentication of client certificate by Nginx Server if “ssl” method enabled in Server configuration (not enabled in TOE configuration).

sha1 fingerprint of the administrator’s certificate.

(A sha1 is used here, as this is the information provided by nginx’s SSL authentication module).

Field ‘user_fingerprint’ Table ‘WaptUsers’ from the ‘wapt’ database.

Extracted from the administrator’s certificate when assigning the certificate to the account in the WAPT Console.

Cryptographic specifications of the administrator workstation hosting the WAPT Console

Cryptographic specifications for the administrator workstation hosting the WAPT Console

Crypto hardware used

Usage

Specifications

Location

Creation / renewal

CA https Servers

Verification of WAPT Server https certificate.

Verification WAPT repository https certificate

X509 Certificate Stores in PEM format (.crt extension).

Each .crt file can contain several approved https Server CAs.

The path to the trusted Store is specified by the verify_cert attribute in the WAPT Agent’s wapt-get.ini file.

Stores are stored in the %LOCALAPPDATA%waptconsolesslserver directory.

The first time the WAPT Console is launched, Stores and Agent configuration are copied.

CA system

Certificate verification for https connections if verify_cert attribute is equal to 1

X509 Certificate Store in PEM format.

File %LOCALAPPDATA%icacert.pem

Automatic extraction from CERTSTORE’s CA and ROOT Stores of the trusted CA system used to verify https certificates.

1h cache

Clients packages and shares

Authentication of imported or edited packages

One X509 Certificate Chain file in PEM format per approved CA.

The first certificate in each file is approved (Key Usage: Digital Signature), the others are any intermediate CAs (Basic constraint: CA, Key Usage: Certificate Sign).

Defined in the ini file %LOCALAPPDATA%waptconsolewaptconsole.ini Key [<repository name>] public_certs_dir

Default: WAPT administrator certificate

WAPT administrator copies certificates for approval.

WAPT administrator certificate

Package signature

Signature of remote actions on WAPT Agents

https authentication on Nginx Server

X509 Certificate Chain in PEM format

The first certificate is the administrator’s certificate, the others are any intermediate CA.

WAPT administrator certificate features:

Key Usage: Digital Signature, Non Repudiation, Data Encipherment

Extended Key Usage: TLS Web Client Authentication

If the administrator is authorized by the organization to sign packages with python code, the certificate must also have:

Extended Key Usage: Code Signing

%USERPROFILE%private<keyname>.crt

Created and renewed by the organization.

WAPT administrator private key

Signing WAPT packages.

Signature of actions to WAPT Agents

Signature by cRSA 2048 bits, PKCS#8 password-encrypted format. PBKDF2 password derivation with 800 iterations, hmac-sha256.AES-256-CBC encryption

Share and package signature type: RSA-SHA256 without padding

%USERPROFILE%private<keyname>.pem

Created by the organization.

Ticket Kerberos Windows session WAPT administrator

Initial authentication (login) to the WAPT Server

Windows session

Private key password

WAPT Administrator private key decryption to sign actions and packages

Kept encrypted in the WAPT Console’s memory space by an ephemeral secret also in the WAPT Console’s memory and by a random secret specific to the user’s session and stored in the user’s private directory.

Password WAPT administrator account

Initial authentication (login) to the WAPT Server

idem

WAPT Console certificate

Client https authentication to Nginx Server for Console session.

Temporary X509 certificate in PEM format signed by CA PKI Agents WAPT. Validity period equal to the duration of session cookies.

Temporary user directory

Signed by the CA PKI WAPT Agents on the Server after successful Kerberos authentication of the Console.

Private key WAPT Console

Client https authentication to Nginx Server for Console session.

Temporary encrypted 2048-bit RSA key. PKCS#8 format encrypted by 120-character random password encrypted in memory by session key. PBKDF2 password derivation with 800 iterations, hmac-sha256. AES-256-CBC encryption

Temporary user directory

Generated by the Console each time you log in.

Cryptographic specifications for client workstations equipped with the WAPT Agent

WAPT Agent

Cryptographic specifications for client workstations equipped with the WAPT Agent

Crypto hardware used

Usage

Specifications

Location

Creation / renewal

CA https Servers.

Verification of WAPT Server https certificate. Verification of WAPT repository https certificate.

X509 Certificate Stores in PEM format (.crt extension).

Each .crt file can contain several approved https Server CA.

The path to the trusted Store is specified by the verify_cert attribute in the Agent’s wapt-get.ini file.

Stores are stored in the directory C:program files (x86)waptsslserver.

Initially deployed when the WAPTagent is installed on the client workstation.

Added or updated by WAPT packages dynamic configuration.

Removed by a WAPT package.

CA system.

Certificate verification for https connections if verify_cert attribute is equal to True.

X509 Certificate Store in PEM format.

File %localappdata%icacert.pem.

Automatic extraction from CERTSTORE’s CA and ROOT Stores of the trusted CA system used to verify https certificates.

1h cache.

Client packages and shares.

package authentication and authorization.

Authentication and authorization of actions.

X509 certificate chain in PEM format.

The first certificate in each file is approved, the others are any intermediate CA.

Type of signature for actions and packages: RSA-SHA256 algorithm without padding applied to the sha256 condensate of serialized data.

The “Code signing” function of the certificate is used to authorize or not the execution of python code in the package.

C:program files (x86)waptssl*.crt.

Initially deployed when the WAPT Agent is installed on the client workstation.

Add or update with dynamically configured WAPT packages.

Withdrawal via a WAPT package.

WAPT Agent Certificate.

Client https authentication to Nginx Server. Signature of inventory data.

X509 certificate in PEM format signed by CA PKI WAPT Agents.

C:program files (x86)waptprivate<agent UUID>.crt.

Signed when a WAPT Agent is registered after successful Kerberos authentication of the Agent.

Private key WAPT Agent.

Client https authentication to Nginx Server. Signature of inventory data.

Unencrypted 2048-bit RSA key.

C:program files (x86)waptprivate<agent UUID>.pem.

Generated by the WAPT Agent on installation or when the Agent UUID is changed.

Secret Agent WAPT.

Encrypt authentication tokens for local applications.

64-character random string.

C:Program Files (x86)waptprivatesecret_key.

Randomly generated when the Agent is installed.

Local client applications: waptexit, waptself, wapttray

Cryptographic specifications for client-side applications: waptexit, waptself, wapttray

Crypto hardware used

Usage

Specifications

Location

Creation / renewal

Token Local applications

Authentication of local actions on the WAPT Agent initiated from local applications (on the same machine as the WAPT Agent).

JWT token dated. Algorithm: HS512. Validity: 24 hours. Content: username and groups.

Local application memory.

After authenticating local applications to the WAPT Agent, the WAPT Agent generates a token to authenticate the following actions.

Ticket Kerberos Windows session user.

Windows session.

SF1. Secure communications

The WAPT Agent and WAPT Console use both interpreted Python code and Lazarus / FPC compiled code.

The Lazarus / FPC code uses the mORMot framework for https protocol management, Kerberos client management, X509 certificate operations, and cryptographic operations (Hash, RSA).

The mORMot framework is itself configured and linked to use the OpenSSL library for TLS sockets, asymmetric RSA operations (key generation, encryption, decryption, signing, verification), and X509 certificate operations.

The Python code is linked to the same OpenSSL libraries and uses the following modules:

  • python cryptography and pyOpenSSL modules linked to OpenSSL: used for all RSA cryptographic operations, X509 certificate generation and signature verification in the python WAPT Agent.

  • winkerberos (Windows Agent) / Kerberos (Linux Agent) and requests-kerberos: used to authenticate the WAPT Agent when it first registers with the WAPT Server.

  • Certifi: the authority certificate bundle used for certificate validation is the certificate Store of the operating system running the Agent, Console or Server (certstore Windows under Windows and /etc/ssl/certs/ under Redhat).

All communications between WAPT Agents and the WAPT Server use the https protocol. The Nginx Server uses the system’s TLS layer. The certificate used to encrypt the https connection is generated and configured by the organization as part of its internal https PKI.

SF2. Identification, authentication and access control

Initial WAPT Agent registration

After installation, the WAPT Agent performs an initial registration on the WAPT Server. The initial registration corresponds to the creation of a client certificate, which will be used to authenticate the WAPT Agent:

Agent authentication on the WAPT Server (Kerberos or login/password).

The Agent creates a public/private key pair and sends a CSR to the WAPT Server.

The Server signs the CSR with the “machine” CA.

Server registration of the Agent’s public certificate and its identifier (Bios UUID by default).

The WAPT Agents PKI CA is an internal WAPT CA used only to sign CSR during workstation registration and to validate WAPT Agent authentication on the WAPT Server afterwards. It is generated when the WAPT Server is installed with a 2048-bit key. It is independent of the WAPT Administrators PKI CA or the https client CA.

A CRL file is generated and populated when a machine is deleted from the WAPT inventory.

The PKI Agents WAPT CA and PKI Agents WAPT CRL are integrated into the Nginx service, which handles client certificate authentication.

This means that only machines that have been properly registered on the WAPT Server and not deleted can access the package repository.

The workstation’s initial registration URL is not protected by Nginx client certificate authentication.

For initial authentication of the workstation during registration, the workstation uses the machine’s Kerberos account to retrieve a service ticket for the WAPT service, which will then be used to authenticate the Agent for registration with the Server. Once the workstation has been registered and the client certificate signed, the WAPT Agent will no longer use Kerberos, but only certificate authentication on the WAPT Server.

Agent websocket connection

Agent websockets connections are made over the same https channel as other connections, with an upgrade after the first exchange. The WAPT Agent uses its WAPT Agent Certificate to authenticate itself on the Nginx Server. If authentication fails, the Agent will try to re-register (see previous paragraph).

As a reminder, no connection is initiated by the Server to the Agents.

Agent login for inventory feedback

Inventories are uploaded over the https connection. Authentication is performed with the WAPT Agent Certificate by the Nginx Server. If authentication fails, the workstation will attempt to re-register.

Connecting Agents to download packages

package index and packages are downloaded over the https connection. Authentication is performed with the WAPT Agent Certificate by the Nginx Server.

Server authentication by Agents

The client authenticates the WAPT Server using the https Server CA.

Authentication of deposit(s) by Agents

The client workstation authenticates the WAPT repository using the https Server CA.

Remote actions on Agents

It is possible, from the WAPT Console, to send actions to WAPT Agents, such as “update the list of available updates”, “launch installations of available updates”, etc. These various actions are initiated from the WAPT Console and relayed by the WAPT Server to the Agents via the existing websocket.

Communication between the Console and the WAPT Server is via the https channel. Communication between the WAPT Server and the WAPT Agent is via the websocket previously set up by the Agent.

Administrator authentication on the WAPT Console

Following installation of the WAPT Server, the first authentication is performed using the “admin” account and the password entered when running the postconf. This account is used to finish configuration and define ACL for WAPT administration accounts defined in Active Directory. Following this initial configuration, “admin” ACL can be assigned to named Active Directory accounts.

Authentication on the WAPT Server uses these domain accounts.

In addition, access to the WAPT Server and WAPT repository is protected on the Nginx Server by client certificate authentication based on the WAPT Agents PKI CA.

SF3. Data protection

The data protection functions do not use cryptographic procedures and are based entirely on the security of the file system.

SF4. Cryptographic functions: Authenticity and integrity

Signature of control file attributes

When signing a WAPT package, the package’s sensitive attributes are listed in the signed_attributes attribute.

The attributes listed in signed_attributes are signed with the Administrator’s private key and the signature is stored in the signature attribute of the control file.

The certificate associated with this private key is stored in the <wapt>certificate.crt file inside the WAPT package.

On the WAPT Server, during the wapt-scanpackages operation (triggered by the addition or deletion of a package), the Packages index is regenerated.

The WAPT Server extracts the signer’s certificate from each package and adds it to the Packages ZIP file, in the <wapt>/ssl directory. Each certificate is named with its hexadecimal-encoded fingerprint.

When the WAPT Agent performs an update, it downloads the Packages index file, which contains both the signed attributes of all packages and the certificates of the signatories. If the certificate of the signatory of a package’s attributes is approved (meaning that the certificate is signed by a Certification Authority or that the certificate itself is trusted), AND the signatory’s certificate can verify the signature of the attributes, the package is added to the index of available packages, otherwise it is ignored.

Signing WAPT packages

When an Administrator or a Package Developer builds a WAPT:

A <wapt>/manifest.sha256 file is created which lists the checksums of all the files in the package.

A signature.sha256 file encrypted with the private key is then created in the WAPT folder, containing the checksum of the <wapt>/manifest.sha256 file.

All files are archived in ZIP format with the .wapt extension.

When a WAPT Agent downloads a WAPT package, the Agent checks that the signature.sha256 file has been signed with the private key that corresponds to the package’s <wapt>/certificate.crt certificate.

The WAPT Agent then verifies that the certificate (or certificate chain) certificate.crt has been signed with a private key corresponding to one of the certificates in the <wapt>ssl folder.

The WAPT Agent then checksums all the files in the package (except the signature.sha256 and certificate.crt files) and verifies that the checksum matches the <wapt>manifest.sha256 file contained in the package.

If one of these steps is not validated, this means that a file has been modified / added / deleted. In this case, execution of setup.py is cancelled.

The faulty package is then deleted from the local cache; the event is reported in the Agent logs.

SF5. Tamper protection

Microsoft Authenticode” signature for binaries and installers.

We use the standard mechanism integrated into Windows. Binaries are signed in the build chain with a “Code signing” Extended Validation certificate issued by an authority validated by Microsoft.

The timestamping Server used is http://timestamp.sectigo.com.

Checking the installer hash with waptdeploy

The waptdeploy utility is responsible for silently launching the waptagent.exe installer with elevated rights.

To guarantee the authenticity of the installer, we check that the sha1 fingerprint of the installer’s “Authenticode” signature certificate is one of those used by Tranquil IT. This list is integrated into the waptdeploy.exe binary when waptdeploy.exe is compiled. The integrity of this list is ensured by the signature of the waptdeploy.exe binary.

The waptagent.exe installer is the aggregation of a standard waptsetup.exe binary (signed by Tranquil IT) and a json variable part for organization-specific configuration (in particular WAPT Server and repository URLs, authorized package certificates, trusted https certificates). To guarantee the integrity of the “Installer” + specific configuration set, a sha256 fingerprint is supplied as an argument to the waptdeploy utility. After downloading waptagent.exe and before running it in silent mode, waptdeploy checks that the waptagent.exe fingerprint matches the one supplied as an argument. The integrity of the –hash argument is ensured by the ACL on the GPO in which this command line is specified. It is the responsibility of the organization’s administrator to ensure that the installer fingerprint in the GPO is correct.

SF6. Logging

Signing requests sent to WAPT Agents

Commands are signed by the WAPT Console before being sent individually to each WAPT Agent.

All action request attributes are signed:

the UUID of the Agent concerned;

action (e.g. install);

arguments (e.g. tis-firefox);

request time stamping.

The certificate associated with the signature is also passed. When the WAPT Agent receives a request, it checks:

That the UUID mentioned in the action corresponds to its UUID.

That the associated certificate comes from an authority present in its <wapt>/ssl directory.

That the request is correctly signed by the certificate key.

That the signature date is within the time interval defined in the WAPT Agent configuration.

Information on data processing

None