[tor-dev] adding smartcard support to Tor

Razvan Dragomirescu razvan.dragomirescu at veri.fi
Sun Oct 18 09:08:13 UTC 2015

Thank you Ivan!

On Sun, Oct 18, 2015 at 1:44 AM, Ivan Markin <twim at riseup.net> wrote:

> Not exactly. The trick is that keys are not the same. For more details
> have a look at the specifications [1]. There is a "permanent key"
> ("holds the name", signs descriptors) and an "onion key" [2] for each
> Introduction Point to communicate with the HS. So the "nameholder" key
> ("permanent") is used only for signing descriptor with a list of IPs and
> corresponding keys.
Ah, I understand now! That actually makes perfect sense for my application.
If I understand it correctly, I can simply let Tor register the HS by
itself (using a random HS name/key), then fetch the introduction points and
keys and re-register them with a different HS name - this would make the
service accessible both on the random name that the host has chosen
(without talking to the card) and on the name that the card holds the
private key to (registered out of band, directly by a script that looks
like OnionBalance).

> > 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.

> If somebody already knows your
> backend keys then certainly they know any of your data on this machine.
> No, not exactly :). There's still one thing they don't have access to -
the smartcard! Even on a completely compromised backend machine, they still
can't make the smartcard do something it doesn't want to do. In my project,
it is the smartcard that drives the system - so a smartcard on one system
can ask the host to connect it to a similar smartcard on a different system
by giving it the HS name. The host establishes the connection, then the two
smartcards establish their own encrypted channel over that connection. A
compromised host can only deny service or redirect traffic somewhere else,
but still can't make the smartcard accept injected traffic and can't
extract the keys on it. I'm basically using Tor as a transport layer with
NAT traversal and want to tie the HS names to smartcards so that I have a
way to reach a _specific_ card/endpoint.

 Thanks again!

Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151018/c50a13cf/attachment-0001.html>

More information about the tor-dev mailing list