<div dir="ltr">A better link for the Mediatek Linkit 7688 board I'm using for PoC is <a href="https://www.seeedstudio.com/item_detail.html?p_id=2573">https://www.seeedstudio.com/item_detail.html?p_id=2573</a> . I'm also doing a second PoC on a Raspberry Pi Zero - <a href="https://www.raspberrypi.org/products/pi-zero/">https://www.raspberrypi.org/products/pi-zero/</a> - far more powerful than the Linkit 7688 above and also cheaper, but a lot harder to find.<div><br></div><div>Razvan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 26, 2016 at 3:32 PM, Razvan Dragomirescu <span dir="ltr"><<a href="mailto:razvan.dragomirescu@veri.fi" target="_blank">razvan.dragomirescu@veri.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you s7r, Tom,<div><br></div><div>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 <a href="https://www.swissbit.com/ps-100u/" target="_blank">https://www.swissbit.com/ps-100u/</a> ). </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'm very close to having a fully functional proof of concept on this tiny board <a href="https://labs.mediatek.com/site/global/developer_tools/mediatek_linkit_smart_7688/whatis_7688/index.gsp" target="_blank">https://labs.mediatek.com/site/global/developer_tools/mediatek_linkit_smart_7688/whatis_7688/index.gsp</a> . 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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>If you have any questions, feel free to ask.</div><div><br></div><div>Thanks,</div><span class=""><div>Razvan</div><div><br></div><div>--</div><div>Razvan Dragomirescu</div><div>Chief Technology Officer</div><div>Cayenne Graphics SRL</div></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Jun 26, 2016 at 1:29 AM, s7r <span dir="ltr"><<a href="mailto:s7r@sky-ip.org" target="_blank">s7r@sky-ip.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hello,<br>
<br>
If you hash the consensus entirely, yes that should produce unique<br>
hashes every time that are unpredictable until the consensus is available.<br>
<br>
However, you cannot guarantee it will be the same value for everyone at<br>
a given time, because consensus documents overlap and two clients/relays<br>
might work properly but not use exactly the same consensus at a given<br>
time (at 13:45 "Y" uses consensus document valid after 12:00 and "Z"<br>
uses consensus document valid after 13:00. Both are within their<br>
valid-until limits).<br>
<br>
I don't recommend that your rely on what you've suggested because of<br>
pour security properties and too complicated design with too many<br>
possible failure cases to be worth it.<br>
Very soon Tor will include an unique random value we call "Consensus<br>
Shared Randomness [SRVALUE]" in every consensus, you can just use that.<br>
This is proposal 250. This seams like a better standardized upstream<br>
solution with infinite better security properties, so I'd use this as a<br>
cookie. This has the advantage of having the same unique value on all<br>
nodes all the time: just filter and pair consensus SRVALUE + consensus<br>
valid-after timestamp and everyone will be requesting the SRVALUE of the<br>
same consensus, therefor producing the same result or fail if none.<br>
<br>
Last but not least, how will your system work in practice? The hidden<br>
service private key will be stored on a smartcard and it cannot be<br>
copied, it will only sign descriptors at the request of the host. So far<br>
so good, but the smartcard has to stay plugged in the host all the time,<br>
or at least all the time the hidden service is running, so what's the<br>
security property here?<br>
<br>
If you think you can manually plug in the smartcard rarely just to sign<br>
descriptors and keep it somewhere else physically most of the time, this<br>
will not work. In the wild things happen that demand new descriptors to<br>
be signed in an unpredictable way: introduction points go offline;<br>
HSDirs go offline, too many INTRODUCE2 cells received on a single<br>
introduction point circuit.<br>
<br>
And if the private key is on a smartcard, and the smartcard is plugged<br>
in the host all the time, what's the gain? I am not saying there isn't<br>
any, I just don't see it at this moment. One I can think of is that<br>
malware and/or someone hacking can't copy the private key and hijack the<br>
hidden service, but the risk remains in case someone physically sizes<br>
the server ("host").<br>
<br>
Do note that next generation of hidden services will support natively<br>
offline keys and actually allow the hidden service to run properly: the<br>
offline keys will generate blinded signing keys, which are used to sign<br>
descriptor signing keys.<br>
<div><div><br>
<br>
On 6/26/2016 12:52 AM, Razvan Dragomirescu wrote:<br>
> Hello everyone,<br>
><br>
> I couldn't find a detailed description of the Tor consensus, so I'm<br>
> checking that my understanding of it is correct. Basically, would it be<br>
> correct to assume that the consensus document (or a hash thereof) for a<br>
> date in the future is an unpredictable value that will also be unique to<br>
> all nodes inquiring about it at that time?<br>
><br>
> I'm thinking of using a hash of the consensus document -<br>
> like <a href="http://171.25.193.9:443/tor/status-vote/current/consensus" rel="noreferrer" target="_blank">http://171.25.193.9:443/tor/status-vote/current/consensus</a> - as a<br>
> descriptor cookie in a hidden service. This way, an attacker cannot<br>
> generate or publish a hidden service descriptor for the future (one with<br>
> a correct cookie). A client can fetch the consensus at the time it wants<br>
> to connect, hash it, then use that as the descriptor cookie to determine<br>
> the correct descriptor id and decrypt the introduction point list.<br>
><br>
> Does anyone see any issues with this? In my project, the hidden service<br>
> private key is on a smartcard, so it can't be copied, you can only ask<br>
> the smartcard to sign something with it for you - and I'm trying to<br>
> prevent an attacker from generating hidden service descriptors in<br>
> advance,to be used without the smartcard. If future descriptors depend<br>
> on an unpredictable future value (the hash of the consensus at that<br>
> time), an attacker can only generate descriptors for past and current<br>
> time periods.<br>
><br>
> Thank you,<br>
> Razvan<br>
><br>
> --<br>
> Razvan Dragomirescu<br>
> Chief Technology Officer<br>
> Cayenne Graphics SRL<br>
<br>
</div></div><br></div></div><span class="">_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>