Client/Server Data Security

Access Key and Secret Key Certification

After the Central Service receives the request from the Agent Service, it uses the same SK corresponding to the AK and the authentication mechanism to generate the authentication string. It then compares it with the authentication string contained in the user request. If the authentication strings match, it considers the user with the specified operation authority and executes relevant operations. If they are different, it ignores the operation and returns an error code.

mTLS channel

When the Agent Service and the Central Service make API data requests and responses, they use the mTLS channel for data exchange. Usually, in TLS, the server has a TLS certificate and a public/private key pair, while the client does not. The typical TLS process works as follows:

• Client connects to server
• Server presents its TLS certificate
• Client verifies the server's certificate
• Client and server exchange information over an encrypted TLS connection

In mTLS, however, both the client and server have a certificate, and both parties authenticate using their public/private key pair. Compared to regular TLS, there are additional steps in mTLS to verify both parties:

• Client connects to server
• Server presents its TLS certificate
• Client verifies the server's certificate
• Client presents its TLS certificate
• Server verifies the client's certificate
• Server grants access
• Client and server exchange information over an encrypted TLS connection

What can mTLS do?

mTLS (Mutual Transport Layer Security) provides secure and trusted two-way communication between a client and server by authenticating both parties using TLS certificates. mTLS offers additional security for users logging into an organization's network or applications and verifies connections between the server and client devices without a login process, such as Internet of Things (IoT) devices.

mTLS prevents various kinds of attacks, including:

• On-path attacks: On-path attackers intercept or modify communications between the client and server. mTLS makes it nearly impossible for on-path attackers to carry out a successful attack, as they cannot authenticate to either the client or the server.
• Spoofing attacks: Spoofing attacks involve imitating a web server to a user or vice versa. When both sides have TLS certificates and authentication, spoofing attacks become significantly more difficult to execute.
• Credential stuffing: Attackers try to log in as legitimate users by using leaked credentials from a data breach. mTLS denies successful credential stuffing attacks, as attackers need a legitimately issued TLS certificate.
• Brute force attacks: Attackers use bots and rapid trial-and-error attempts to guess user passwords. mTLS ensures a password alone is not enough to access an organization's network. Rate limiting is another method to mitigate brute force attacks.
• Phishing attacks: Attackers aim to steal user credentials to compromise a network or application. Even if a user falls for a phishing attack, the attacker needs a TLS certificate and corresponding private key to use the stolen credentials.
• Malicious API requests: For API security, mTLS verifies that API requests come from legitimate, authenticated users only. This prevents attackers from sending malicious API requests that exploit vulnerabilities or interfere with the intended API functions.

IP Whitelist in both VASP and Central Service

When the proxy service and central service make requests, IP whitelists are supported. IP whitelisting effectively prevents proxy IP addresses from being abused by ensuring that only authorized IP addresses can access the services.