[tor-dev] getting reliable time-period without a clock

Razvan Dragomirescu razvan.dragomirescu at veri.fi
Mon Jun 20 16:59:53 UTC 2016

Thank you Ivan,

I don't want to trust the host, that's why I'm looking for something that
the _network_ agrees upon, not something the host can provide or generate
itself. If the host fetches the Facebook hidden service descriptor and
provides it to the card, the card can check the signature on it, then look
at the time it was generated and compute the time period for it, then set
its internal "clock" to that time. Unless the host can trick Facebook into
using the wrong date (a future date), this should work fine.

An alternative that I don't want to use is to simply run a hidden service
of my own that simply returns a signed statement of time ("current time at
this server is HH:MM:DD"  + RSA Signature). But I don't want the system to
depend on a centralized service like this, if the network already agrees on
what is the current time (or time period), I want to use that.

I'll take a look at the doc you've linked to, thank you!


Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Mon, Jun 20, 2016 at 7:51 PM, Ivan Markin <twim at riseup.net> wrote:

> Hello Razan,
> Razvan Dragomirescu:
> > I am working on a smartcard-based hidden service publishing solution and
> > since I'm tying the hidden service descriptor to the physical smartcard,
> I
> > want to make sure that the host is not asking the smartcard to generate
> > hidden service descriptors in advance, to be used when the card is no
> > longer inserted into the host/reader.
> Just for the record, currently it's a problem that is going to be solved
> by introducing shared random randomness [1].
> > The smartcard has no internal clock or time source and it's not supposed
> to
> > trust the host it's inserted into, so I need an external trusted source
> > that indicates the current time period. I'm not 100% familiar with the
> Tor
> > protocol (minus the hidden service parts I've been reading about
> recently),
> > so is there any way to get a feel of what the network thinks is the
> current
> > time or the current time-period? An idea would be to fetch the Facebook
> > hidden service descriptor or some other trusted 3rd party hidden service
> at
> > a known address and see if the time period given to the smartcard is
> valid
> > for that Facebook descriptor too. An operator could set up  one or more
> > trusted hidden services to match against the time-period (inside the
> > smartcard) before it signs a given descriptor.
> Hmm, you seem to trust untrusted host here since you trust tor daemon
> running on the host for clock fetching.
> Anyway you're proposing to offload more tor logic onto the smartcard
> thus making it trusted host. For me it seems to be unreasonable for such
> tiny amount of resources it has. The only functon of a smartcard is to
> store private keys in secure manner (do not expose them, only use them).
> I think that a possible solution to this is to have some trusted
> air-gapped host with the smartcard that generates chunks of signed
> descriptors. This trusted host can check if the digest is legit. Then
> you can transfer the digests to a "postman" machine which just uploads
> these descriptors.
> [ha-ha, ironically, I'm currently creating such setup right now. I'm
> transferring signed digests via UART]
> [1]
> https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt
> --
> Healthy bulbs,
> Ivan Markin
> _______________________________________________
> 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/20160620/7cca8443/attachment-0001.html>

More information about the tor-dev mailing list