[tor-dev] is the consensus document unpredictable / unique?

Sun Jun 26 12:35:33 UTC 2016

A better link for the Mediatek Linkit 7688 board I'm using for PoC is
https://www.seeedstudio.com/item_detail.html?p_id=2573 . I'm also doing a
second PoC on a Raspberry Pi Zero -
https://www.raspberrypi.org/products/pi-zero/ - far more powerful than the
Linkit 7688 above and also cheaper, but a lot harder to find.

Razvan

On Sun, Jun 26, 2016 at 3:32 PM, Razvan Dragomirescu <
razvan.dragomirescu at veri.fi> wrote:

> Thank you s7r, Tom,
>
> I'll try to explain what I'm doing - I'm working on something called
> SIM4Things - it's an Internet of Things project, giving Internet-connected
> objects a persistent, cryptographically secure identity and a way to reach
> similar objects. The closest analogy is the SIM card in the GSM / mobile
> world (hence the name :) ). The identity is actually an RSA keypair, stored
> in a tamper-resistant microSD form factor secure element (like this one
> https://www.swissbit.com/ps-100u/ ).
>
> The project does multiple things - first, it gives the node an identity -
> the RSA private key inside is used to sign a hidden service descriptor (a
> la OnionBalance) that is then published. As long as the device has access
> to the smartcard, it can sign descriptors. Once the card is removed, it can
> no longer do that.
>
> Second, using hidden services means that the devices become accessible at
> a single .onion address regardless of how they connect to the Internet and
> how many firewalls and/or NAT gateways they are behind.
>
> I'm very close to having a fully functional proof of concept on this tiny
> board
> https://labs.mediatek.com/site/global/developer_tools/mediatek_linkit_smart_7688/whatis_7688/index.gsp
> . It runs OpenWRT. A Python script using STEM connects to Tor and to the
> internal smartcard, fetches the hidden service descriptor as published by
> Tor and modifies / re-signs it to point to the address associated with its
> public key (keeps the introduction points, rewrites everything else). I
> know this will no longer work with Prop 224 but afaik Prop224 is still 1-2
> years away. Once the new descriptor is published, the node can talk to any
> other similar node over the Tor network.
>
> I want to offer the same guarantees that a regular SIM card inside your
> phone would offer - as long as you have the SIM, you can join the network
> and talk to other nodes. Once the SIM is gone, you should no longer be able
> to do so. It should also be impossible (or very hard) to clone such a SIM
> card and it should be impossible (or hard) to generate hidden service
> descriptors in advance (that would allow you to join the network even after
> the SIM has been removed).
>
> So, to summarize - I'm doing a SIM card for the Internet of Things. The
> SIM is a microSD tamper-resistant secure element with an RSA key inside. It
> gives the node an identity (strongly tied to the physical SIM) and a way to
> talk to similar nodes, with no central server or censorship opportunity.
>
> If you have any questions, feel free to ask.
>
> Thanks,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
> On Sun, Jun 26, 2016 at 1:29 AM, s7r <s7r at sky-ip.org> wrote:
>
>> Hello,
>>
>> If you hash the consensus entirely, yes that should produce unique
>> hashes every time that are unpredictable until the consensus is available.
>>
>> However, you cannot guarantee it will be the same value for everyone at
>> a given time, because consensus documents overlap and two clients/relays
>> might work properly but not use exactly the same consensus at a given
>> time (at 13:45 "Y" uses consensus document valid after 12:00 and "Z"
>> uses consensus document valid after 13:00. Both are within their
>> valid-until limits).
>>
>> I don't recommend that your rely on what you've suggested because of
>> pour security properties and too complicated design with too many
>> possible failure cases to be worth it.
>> Very soon Tor will include an unique random value we call "Consensus
>> Shared Randomness [SRVALUE]" in every consensus, you can just use that.
>> This is proposal 250. This seams like a better standardized upstream
>> solution with infinite better security properties, so I'd use this as a
>> cookie. This has the advantage of having the same unique value on all
>> nodes all the time: just filter and pair consensus SRVALUE + consensus
>> valid-after timestamp and everyone will be requesting the SRVALUE of the
>> same consensus, therefor producing the same result or fail if none.
>>
>> Last but not least, how will your system work in practice? The hidden
>> service private key will be stored on a smartcard and it cannot be
>> copied, it will only sign descriptors at the request of the host. So far
>> so good, but the smartcard has to stay plugged in the host all the time,
>> or at least all the time the hidden service is running, so what's the
>> security property here?
>>
>> If you think you can manually plug in the smartcard rarely just to sign
>> descriptors and keep it somewhere else physically most of the time, this
>> will not work. In the wild things happen that demand new descriptors to
>> be signed in an unpredictable way: introduction points go offline;
>> HSDirs go offline, too many INTRODUCE2 cells received on a single
>> introduction point circuit.
>>
>> And if the private key is on a smartcard, and the smartcard is plugged
>> in the host all the time, what's the gain? I am not saying there isn't
>> any, I just don't see it at this moment. One I can think of is that
>> malware and/or someone hacking can't copy the private key and hijack the
>> hidden service, but the risk remains in case someone physically sizes
>> the server ("host").
>>
>> Do note that next generation of hidden services will support natively
>> offline keys and actually allow the hidden service to run properly: the
>> offline keys will generate blinded signing keys, which are used to sign
>> descriptor signing keys.
>>
>>
>> On 6/26/2016 12:52 AM, Razvan Dragomirescu wrote:
>> > Hello everyone,
>> >
>> > I couldn't find a detailed description of the Tor consensus, so I'm
>> > checking that my understanding of it is correct. Basically, would it be
>> > correct to assume that the consensus document (or a hash thereof) for a
>> > date in the future is an unpredictable value that will also be unique to
>> > all nodes inquiring about it at that time?
>> >
>> > I'm thinking of using a hash of the consensus document -
>> > like http://171.25.193.9:443/tor/status-vote/current/consensus - as a
>> > descriptor cookie in a hidden service. This way, an attacker cannot
>> > generate or publish a hidden service descriptor for the future (one with
>> > a correct cookie). A client can fetch the consensus at the time it wants
>> > to connect, hash it, then use that as the descriptor cookie to determine
>> > the correct descriptor id and decrypt the introduction point list.
>> >
>> > Does anyone see any issues with this? In my project, the hidden service
>> > private key is on a smartcard, so it can't be copied, you can only ask
>> > the smartcard to sign something with it for you - and I'm trying to
>> > prevent an attacker from generating hidden service descriptors in
>> > advance,to be used without the smartcard. If future descriptors depend
>> > on an unpredictable future value (the hash of the consensus at that
>> > time), an attacker can only generate descriptors for past and current
>> > time periods.
>> >
>> > Thank you,
>> > Razvan
>> >
>> > --
>> > Razvan Dragomirescu
>> > Chief Technology Officer
>> > Cayenne Graphics SRL
>>
>>
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160626/425ab62f/attachment-0001.html>