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

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL


On Mon, Jun 20, 2016 at 7:51 PM, Ivan Markin <twim@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev