Ivan, according to https://www.torproject.org/docs/hidden-services.html.en (maybe I misunderstood it), at Step 4, the client sends an _encrypted_ packet to the hidden service, so the hidden service needs to be able to decrypt that packet. So the key on the card needs to be used both for signing the HS registration and for decrypting the packets during the initial handshake, isn't this correct?
As far as I could tell, there is no way to tell Tor to use a smartcard in any phase of the protocol, your OnionBalance tool simply handles the registration by itself (outside of Tor).
Regarding bandwidth, this is for an Internet of Things project, there's very little data going back and forth, I only plan to use the Tor network because it's a very good way of establishing point to point circuits in a decentralized manner. The alternative would be to use something like PubNub or Amazon's new IoT service, but those would depend on PubNub/Amazon.
Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On Sat, Oct 17, 2015 at 10:13 PM, Ivan Markin twim@riseup.net wrote:
Razvan Dragomirescu:
Thank you Ivan, I've taken a look but as far as I understand your project only signs the HiddenService descriptors from an OpenPGP card. It still requires each backend instance to have its own copy of the key (where it can be read by an attacker). My goal is to have the HS private key exclusively inside the smartcard and only sign/decrypt with it when
needed
but never reveal it.An attacker should not be able to steal the key and host his own HS at the same address - the address would be effectively
tied
to the smartcard - whoever owns the smartcard can sign HS descriptors and decrypt traffic with it, so he or she is the owner of the service.
Yes, it still requires to have plain keys for decryption of traffic on backend instances, sure. But you're not right about key "stealing" (copying). An address of a HS is calculated from key which is signing descriptors. This key resides on a smartcard. It's already "the-address-would-be-effectively-tied-to-the-smartcard" situation there.
I do not see any reason to decrypt traffic on a smartcard; in case if an attacker can copy your backend key there is no need to decrypt anything
- they already have an access to the content on your instance. Also
backend instances' keys are disposable - you can change them seamlessly.
P.S. Notice about bandwidth issue when you're decrypting all of the traffic on a smartcard (half-duplex, etc.).
-- Ivan Markin /"\ \ / ASCII Ribbon Campaign X against HTML email & Microsoft / \ attachments! http://arc.pasp.de/
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev