Tor HS keys password protection against impersonation attacks?
Hi, thinking about Tor Hidden services, they are managed by using Hidden Services client keys. The Tor HS keys are "private keys" that may require to be protected because they represent also the "identity" of the Tor HS and if stolen, it would be possible to carry on impersonation attack on connecting to Tor HS. Accepting connections on behalf of the real TorHS, with the goal to steal passwords, provide fake data to clients, exploit them, etc. The Tor HS keys are even more sensible than the X509v3, as it does provide: - identity (similar to an internet domain name) - routing (similar to an internet IP address) - encryption (they provide e2e encryption, i don't know if there are attacks on crypto if they get stolen) So owning a Tor HS key it's like owning a user domain name, acquiring it's ip address and the x509v3 private key of his digital certificate bound to his domain name. As a protection schema it would be possible to create the Tor HS private key encrypted with a passphrase, like it's possible to do for x509v3 PEM certificates. That the passphrase to unlock the Tor HS key, could be provided via Tor Control Port, so an external process (UI, scripts) could manage the setup of the passphrase. That way even in case of seizure of the server running the Tor HS it would not be possible to who seized the Tor HS Server to do actively Impersonation attacks of the Tor HS. -naif
On 2012-03-17 10:52 , Fabio Pietrosanti (naif) wrote: [..]
If you want to protect these files, use proper full disk crypto, that will solve all your data issues up to that level, eg somebody taking the disk and trying to attack it from that perspective. Do note that not all FDEs are actually truly secure... and it all depends on what one is protecting against. If one can get access to a running installation so that they can retrieve/access the file you store your keys in you have lost more than just your identity, they can then also subvert the machine by changing binaries on the system, inserting code into running processes etc etc or just monitoring the thing, likely with the data that goes inside the tunnel. Another way to solve this is to do SSL/TLS/SSH inside the Tor connection and use that for authentication of client and server, which is probably the best thing you can do to protect your data, as the legs between your client and the Tor instance and the remote HS Tor instance and the app are not 'protected' by the layer that Tor provides oh and those legs are perfectly inspectable with tcpdump. Greets, Jeroen
On 3/17/12 11:02 AM, Jeroen Massar wrote:
I mean, the password protection is not in any case to protect against such threat scenario. It's like the ability for Apache to be able to decrypt the RSA key of an X509v3 digital certificate at it's startup (or restart) by asking the administrator a password. So: - You are protected against computer seizure (that imply a shutdown) - You are not protected against intrusion Still making a little slightly difficult to retrieve it for the attacker requiring him to dump memory, dissect it, extract the key rather than just copying a file. Obviously this is not the scope of protection of adding a password protection of a Tor HS key, but against computer. -naif
On 03/17/2012 02:52 AM, Fabio Pietrosanti (naif) wrote:
I think that's a great idea but also a UI nightmare; for servers, I think arm would need to support entering the key and for desktops, I think Vidalia is the obvious target. It would probably be good to have the key decryption tied together with something like scrypt[0] to make it really expensive to bruteforce. All the best, Jacob [0] http://www.tarsnap.com/scrypt.html
On 3/18/12 3:34 AM, Jacob Appelbaum wrote:
Well, for server it could also be possible to start implementing something simpler such as a password inquiry on stdin like Apache does. That way the "core functionalities" of the TorHS password protection may be implemented and get used, while delegating to a second stage the opportunity to unlock the key via Tor ControlPort for better UI integration. -naif
participants (3)
-
Fabio Pietrosanti (naif) -
Jacob Appelbaum -
Jeroen Massar