Re: [tor-dev] adding smartcard support to Tor

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev