idea for application

Name and Description of application

Name: clientguard

Description: this application is a VPN application that would ideally be open source.

The idea  is to make a hardware-enforced, no logging VPN protocol that would secure devices VPN traffic from even the VPN company itself.

How would it work?

If you are in IT, you will know most VPN providers use server side key generation. This is because VPNs, as stated by palo alto networks , were used to securely connect to private networks.

These are the norms, such as openvpn , ipsec , and even wireguard .

The problem

Server side key generation allows for administrators of the VPN provider to read logs of traffic and decrypt traffic.

The idea is to have no logging by making the key generation client side, meaning all the key generation happens locally, not on the server.

How would the key generation  work?

The client would work in 2 ways

The first way is using the trusted execution environment or secure enclave of the computer. Examples include: on android, trusty (android open source project) , or on IOS,  or on IOS, it would use the apple secure enclave

On windows, depending on a processor type, you can either have the intel TDX  or AMD TEE

The  only reliable tee however, is trusty due to it having an open source capability.

The problem with blackboxes, such as TdX, apples secure enclave, etc, is that you do not necessarily know what code is on it, and  the problem with that is if a vulnerability has been executed and it even partially relies on is remote code execution, this means your TEE has been tanked!

The solution to this is to store keys on a hardware security module that is open source.

An example of this is the   nitrokey HSM   which securely stores keys, and can be exported anywhere.

As an added benefit is the fact that if PKCS#11 libraries are programmed into the keys rust APIs, you will be able to conduct perfect forward secrecy  which will allow secure key deletion and rotation, meaning that a key compromise will not compromise the entire session.

Cryptography

Since we will theoretically use asymmetrical encryption, we should use algorithms such as kyber and dilithium  for post quantum cryptography algorithms.

This will allow for post quantum encryption.

Note: if you want to build a national security system, this algorithm is part of the commercial national security algorithm sweet 2.0

This key would be used to authenticate  the session and secure the connection itself.

ML-KEM  would be used to encrypt the traffic itself during the connection.

It can both encapsulate and exchange keys, which both allows for confidentiality during receiving of the key, and protection of the traffic.

In an ephemeral key setup, ML-KEM will be able to do perfect forward secrecy.

Rules of the application:

• Keys may not leave the secure enclave, whether it is androids TEE< or a physical hardware key.
• The user must present their key (if hardware key based) before the VPN connects, or else it will not establish a connection.
• If no key is detected, the connection drops.
• The minute the application can no longer connect with the key post-session while the VPN is running, the connection must be dropped, as it is assumed to be a compromise.
• If the session cannot be authenticated, or there is a false signature/a signature the client did not generate onto the key, the connection must not go through, and a warning will be displayed.
• Client side key generation must be local and offline.
• If the signature has been erased from the key, a new one must be generated by the user. Note: keys should be ephemeral, so keys should erase after a period of time (EG: 10minutes, 15minutes).
• The client should assume both the VPN server and the user as hostile  and or stupid, and make sure it will not be easy to transport keys from the secure enclave to memmery/ram.
• Users should have the ability to do key verification to ensure the key the client is generating is a key that can be trusted. EG: pin, etc.
• As a result of the, treat both server and user as stupid, rule, the keys must never enter the host operating system, and stay inside the enclave. Example: if a user uses an iphone, the keys must stay inside of apples secure enclave and must not enter the IOS mobile operating system.
• Similarly, with the HSM, keys must never leave the HSM and enter the host OS. keys must stay inside the HSM at all times.
• Clients must have a form of secure key deletion and rotation for perfect forward secrecy to work. Otherwise, the user will have to generate new keys manually.
• Clients must not have a backdoor to access keys. Nor should there be a master key, as this compromises the security layer.

Where this will not work

• Metadata could be possibly leaked, EG: what websites you visit as this traffic is not protected in the session. For this to work, the VPN server itself needs to be hosted as an onion service to work correctly.
• The VPN client will obviously ask for the server. If not on a proxy or tor, the VPN server will see your host IP address.
• This will not address server based security via server compromise (E.G. a SSH key login, or a program running on the server that uses a RCE vulnerability) so the security of the server is not guaranteed. This will, however, protect the contents of your session, as this requires the client side key, which is never stored on the server.
• This does not address vulnerabilities to the secure enclave, nor does it address vulnerabilities in the HSM devices themselves. This is on the vendor to watch for.
• It is important to note this does not address malware problems, this requires common sense during browsing.
• This also does not address KYC (know your customer) exploits that relate to personally identifiable information (PII) as this has to do with no logging on the user side, not the KYC side. This protocol was not meant to address issues relating to PII or customer data like credit card numbers, real names, addresses, phone numbers, etc. this requires  you to be vigilant about what VPN providers you trust and requires research on KYC laws.
• This will not work if the HSM used is physically stolen, and or an attacker gains access to the secure enclave itself.
• As it relates to proprietary operating systems, this does not stop Microsoft's spyware or services, this is your job to decide whether you are worried about it or not. Note: client side VPNs can be partially bypassed by system applications (E.G. apple app store, google play store, microsoft store) has access outside the VPn layer.

The instructions (process described)

The user, assuming a server is configured by the administrator, inserts their key, or can choose to use the device's secure enclave.

The first key  for the session is generated by the client, which will be a libreSSL or a PKCS#11 library.

If using nitrokey HSM, a rust APi will be used for key generation on key.

After the key is generated, the VPN client verifies that the key is generated, and if key verification is successful, the VPN will connect.

The server will be notified of the connection, however, will not have the key.

The output

The VPN connects, and the connection is secure.

The client also returns the VPN IP address, which a user can type ipconfig or a website like whatismyip.com  to check if the IP is the same. If it matches, the VPN has successfully connected.

After around 15minutes, every time, the key will expire, and a new one will regenerate either on the enclave or the Hsm.

If the HSM is unavailable, the client will not fall back to the builtin device enclave, because it assumes the key is the enclave and not the device.

Possible vulnerabilities

• If the secure enclave on the device os compromised, the key, and any ephemeral keys, will be compromised as well.
• If the computer is compromised, the key could be hijacked during generation, or overridden with the attackers key.
• If the app has been redistributed on a shady site or has a signature not similar to the clientguard signature, then the app might come packed with malware. It is on the user to verify the app installation has not been compromised, and verify that the app signature matches the public sourcecode.
• If the PKCS#11 library in the future has a vulnerability, this could be exploited during or after the keyy generation process to have the key be either overriden, or completely generated by the attacker, while the app may return it as successful or say it is the right key.
• If the attacker has taken control of clientguard server, the attacker will have administrative access to the CG server, meaning they could potentially turn off the VPN, or modify it to gane some access, in which they can cause more damage.

Storage information

• Some metadata, such as your username, is stored on the computer itself.
• Keys, such as for authentication and encryption, are either stored on the device secure enclave, or your HSM.
• The VPN IP is stored on client
• Logs are also stored as encrypted blobs, on both client and the server, and require the key of the session in order to access them.
• The VPN itself is handled by the operating system, so the OS will store data such as  the name of the VPN.
• A PKCS#11 services are stored locally on the client. Note: clientguard (windows)will never use microsoft cryptographic services API because it is proprietary.
• The host IP address, if not on an overlay network such as tor on router levels, will be stored both on client in error logs and server.

Conclusion

Clientguard ames to solve the no VPN logs by using client side key generation to generate cryptographic keys to ensure that logs are not accessible to the server. It generates keys using the secure enclave of a device or TEE (E.G. android trusty, IOS secure enclave, intel TDX) or a hardware security module (E.G. nitrokey) to securely delete, generate, and rotate keys. The keys will never be stored on the device itself or on ram outside of the secure enclave or outside the key, and the server will never be able to grab this key, ensuring privacy.

No key=no VPN logs.