While thinking about TorHS key protection, it would be also nice to think about "re-organizing" the way the TorHS describe store it's data.
One of the example issue i see is that currently the hostname of a TorHS is written to a text file.
This provide two major drawbacks: - Application integration
Any application willing to integrate with Tor and ship Tor together with the application (GlobaLeaks, TorChat, etc) must do a file i/o operation to know the hostname. If the hostname could be known via Tor ControlPort the applications integrating Tor would have a much clean and dynamic way to know it's local TorHS hostname.
- Security issue
Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file.
In the context of protection by using a password to protect the TorHS key, also the hostname information (currently in "hostname" file), would need to be protected. So in such context it would be eventually useful to think about changing the structure of the HiddenServiceDir files, by merging together the "hostname" file and the TorHS key.
Even better it would be cool to have an abstracted "data storage" for such kind of information, so that it would be possible to keep it file based, sql based, remotely hosted over an web services, etc.
Having something like:
HiddenServiceStorage file://etc/tor/hiddenservice HiddenServiceStorage dbm://etc/tor/hiddenservice.db HiddenServiceStorage http://username@password:myremotekeyhostingservice/givemykeys?$%7B%7BTorServ...
While for the protection schema it may have a file protection schema like: HiddenServiceEncryptionMethod pgp, scrypt, plain, exec://usr/bin/customscript
-naif
On 18 Mar 2012, at 12:46, "Fabio Pietrosanti (naif)" lists@infosecurity.ch wrote:
- Security issue
Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file
Why not simply use Full Disk Encryption or similar to protect all the data files, hat avoids a compromise for any file on the system, heck if hey turn the box off they can't even see there is Tor on it at all. also heavily note that the actual content served is likely much more valuable and you will want to protect that too.
Note that you can do this already today and it does not require an changes to Tor.
Greets, Jeroen
On 3/18/12 1:09 PM, Jeroen Massar wrote:
On 18 Mar 2012, at 12:46, "Fabio Pietrosanti (naif)" lists@infosecurity.ch wrote:
- Security issue
Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file
Why not simply use Full Disk Encryption or similar to protect all the data files, hat avoids a compromise for any file on the system, heck if hey turn the box off they can't even see there is Tor on it at all. also heavily note that the actual content served is likely much more valuable and you will want to protect that too.
Yes, but any application that store "sensitive data" like keys should provide an integrated way to protect such sensitive data.
Think about the "keychain" of PGP, or keychain of Firefox for digital certificate, etc, etc
All major applications that need to handle "keys" support a built-in feature to provide different degree of protection for such "keys".
So the idea is to "aggregate" the TorHS related "sensitive information" and apply a protection schema with a "keychain" providing some security feature.
-naif
On 2012-03-18 13:57 , Fabio Pietrosanti (naif) wrote:
On 3/18/12 1:09 PM, Jeroen Massar wrote:
On 18 Mar 2012, at 12:46, "Fabio Pietrosanti (naif)" lists@infosecurity.ch wrote:
- Security issue
Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file
Why not simply use Full Disk Encryption or similar to protect all the data files, hat avoids a compromise for any file on the system, heck if hey turn the box off they can't even see there is Tor on it at all. also heavily note that the actual content served is likely much more valuable and you will want to protect that too.
Yes, but any application that store "sensitive data" like keys should provide an integrated way to protect such sensitive data.
Think about the "keychain" of PGP, or keychain of Firefox for digital certificate, etc, etc
All major applications that need to handle "keys" support a built-in feature to provide different degree of protection for such "keys".
And you want to add another one that has to be separately managed? :)
As I mentioned btw, the Tor keys are not that valuable, the content that sits behind it is though. And if you are doing it right you are actually sending TLS/SSL/SSH through the tunnel instead of clear text.
So the idea is to "aggregate" the TorHS related "sensitive information" and apply a protection schema with a "keychain" providing some security feature.
Which is perfectly done by simply crypting the partition/disk the data is stored on, which additionally will resolve quite a few other attacks too. And the attack vectors that are left open with these is much better understood too.
Note that if you just use non-encrypted storage there is a big chance that the 'old' file is still present on the file system which can give away quite a few details already.
Greets, Jeroen
On 3/18/12 2:40 PM, Jeroen Massar wrote:
On 2012-03-18 13:57 , Fabio Pietrosanti (naif) wrote:
On 3/18/12 1:09 PM, Jeroen Massar wrote:
On 18 Mar 2012, at 12:46, "Fabio Pietrosanti (naif)" lists@infosecurity.ch wrote:
- Security issue
Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file
Why not simply use Full Disk Encryption or similar to protect all the data files, hat avoids a compromise for any file on the system, heck if hey turn the box off they can't even see there is Tor on it at all. also heavily note that the actual content served is likely much more valuable and you will want to protect that too.
Yes, but any application that store "sensitive data" like keys should provide an integrated way to protect such sensitive data.
Think about the "keychain" of PGP, or keychain of Firefox for digital certificate, etc, etc
All major applications that need to handle "keys" support a built-in feature to provide different degree of protection for such "keys".
And you want to add another one that has to be separately managed? :)
Well, that's the point, it must be flexible because it should in theory be possible to hook it on different keychains. It would make perfect sense to integrate it with Mac OSX keychain like already happens for x509v3 certificates.
But it would be also required also to have a "portable" and self-contained keychain. This would be required to be able to work with TBB and/or other portable applications that would like to bundle Tor (TorChat, GlobaLeaks, etc).
-naif
-
Fabio Pietrosanti (naif) -
Jeroen Massar