getting reliable time-period without a clock
Hello everyone, 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. 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. Is there an easier way? I _think_ I can download the current consensus and check signatures on it (who signs it? how do I verify these signatures?), then check the valid-after / valid-until fields inside. The problem with that is its size, it's about 1.6MB - a bit hard for the card to digest that much but doable in small chunks. Any hints would be appreciated. Thank you! Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
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-c... -- Healthy bulbs, Ivan Markin
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-c... -- Healthy bulbs, Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Well, the consensus is the ultimate root of trust for the Tor network. Sample: http://171.25.193.9:443/tor/status-vote/current/consensus It's a very large ASCII document, and you'd need to hardcode one or more DirAuth keys. But it has a timestamp in it. You could provide older consensuses to the smartcard and get it to sign historical data, but not future ones. Before choosing the consensus, I would see which DirAuth-signed document would be best to use. Consensus and microconsensus are two options. I'm nto sure if there's anything else smaller the DirAuths sign... MicroDescriptors? (Unsure.) -tom
participants (3)
-
Ivan Markin -
Razvan Dragomirescu -
Tom Ritter