A Step Forward for Anonymity
Some time ago, I wrote a blog post detailing the basic workings of PrivNet. Although the protection offered by PrivNet remains pretty high, I thought it’d be an interesting exercise to see just how much it’s possible to bolster the defences offered without overtly impacting the end-user experience.
So, introducing PrivNet++
PrivNet works on a pretty simple basis, the user dials into a server and uses that to access the Internet. Thanks to the ubiquitous Pay As You Go mobile phone, it’s now pretty easy to do so without disclosing the details of the phone’s owner.
So using a PAYG phone, the end-user dials the number of the PrivNet PAYG phone. At any point, the SIM card and/or phone can be replaced (although the end-user would obviously need to be given the new gateway number).
PrivNet++ is no different in this respect, the user still dials into the PrivNet PAYG phone and authenticates using PAP/CHAP.
However difficult it may be for ‘interested’ parties to locate and intercept this connection on the Telco’s network, it is still possible. So PrivNet++ introduces stronger on-the-fly encryption to the connection between the client and the PrivNet PAYG phone.
Proxies
Although PrivNet includes support for routing the connection via TOR, PrivNet++ includes the ability to force a remote proxy. Whilst not offering the same level of protection as TOR, it does avoid the issue of compromised endpoints (so long as you can trust the proxy you select!)
Hardware Authentication
In order to minimise the risk of the user unknowingly dialling into a compromised server, PrivNet++ implements a new security scheme. To prevent the PAYG connection being surreptitiously routed to another server, hardware authentication controls are in place;
-
Client holds two secret keys
-
Upon connecting, the client requests credentials
-
Server sends a checksum of the MAC address, Processor serial number and harddrive serial number to the client
-
The client concatenates these values and salts them using it’s stored secret key. A cryptographic hash is then generated and compared to the second key. If not identical, the connection is terminated and the user alerted.
This takes place before the client authenticates itself with the server, and helps to ensure that the client will only connect to the correct server, even if someone were to tamper with the routing of the PAYG data call (an unlikely event anyway).
Tamper Warning
PrivNet++ also incorporates a method for warning the end-user that the server may have been physically compromised/tampered with. When receiving inbound traffic, the server checks for the presence of a secret token, if this is not available the connecting user is warned that the server is unavailable for security reasons and severs the connection.
Although initially planned as a CD, the token could be resident on any piece of hardware though a small USB Flash Drive is likely to be the most convenient.
The client is also configured to expect a checksum of the secret token, and if one is not provided will consider the server compromised and sever the connection.
The server administrator can therefore quickly disable the server and protect the end-user from interception simply by removing a single item from the system.
Once a client has been notified that the server has been compromised, it will blacklist that server and require a password from both the user and the server administrator to re-enable it. It’s expected that this would not happen unless both the Administrator and user are happy that it was a false alarm. Communication is expected to take place using an upcoming terminal chat functionality using a dedicated PAYG connection.
Other Changes
The requirement to use VNC/RDP has been dropped, the PrivNet++ server now incorporates a proxy server that will allow the user to connect via the PrivNet++ server itself. VNC/RDP remains available for those users that require it.
The proxy server has an option to force SSL connections where they are available, so interception on the host connection will be less effective.
The proxy deletes all locally stored cookies whenever a session ends and users are encouraged to clear their cache regularly.
Change in Requirements
PrivNet was intended as a server-side solution, requiring no bespoke software to be installed on the connecting client. However, some of the features of PrivNet++ do require a small client to be installed.
