[tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

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 at veri.fi> wrote:

> 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
>
> --
> 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/949d3696/attachment.html>