[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



Ivan, if I understandÂhttps://onionbalance.readthedocs.org/en/latest/design.html#next-generation-onion-services-prop-224-compatibility correctly, the setup I've planned will no longer work once Tor switches to the next generation hidden services architecture, is this correct? Will there be any backwards compatibility or will old hidden services simply stop working at that point?Â

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Sun, Oct 18, 2015 at 12:08 PM, Razvan Dragomirescu <razvan.dragomirescu@xxxxxxx> wrote:
Thank you Ivan!

On Sun, Oct 18, 2015 at 1:44 AM, Ivan Markin <twim@xxxxxxxxxx> 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

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev