Razvan Dragomirescu:
Thank you Ivan!
You're welcome!
Ah, I understand now! That actually makes perfect sense for my application. If I understand it correctly, I can simply let Tor register the HS by itself (using a random HS name/key), then fetch the introduction points and keys and re-register them with a different HS name - this would make the service accessible both on the random name that the host has chosen (without talking to the card) and on the name that the card holds the private key to (registered out of band, directly by a script that looks like OnionBalance).
Yes, exactly.
If somebody already knows your backend keys then certainly they know any of your data on this machine.
No, not exactly :). There's still one thing they don't have access to -
the smartcard! Even on a completely compromised backend machine, they still can't make the smartcard do something it doesn't want to do. In my project, it is the smartcard that drives the system - so a smartcard on one system can ask the host to connect it to a similar smartcard on a different system by giving it the HS name. The host establishes the connection, then the two smartcards establish their own encrypted channel over that connection. A compromised host can only deny service or redirect traffic somewhere else, but still can't make the smartcard accept injected traffic and can't extract the keys on it. I'm basically using Tor as a transport layer with NAT traversal and want to tie the HS names to smartcards so that I have a way to reach a _specific_ card/endpoint.
The question is what are you trying to protect. With decryption key you're protecting actual content to transmit over the net that is already stored in plaintext. You may regard "onion" keys as "TLS symmetric keys" because they are ephemeral and used "just for one purpose". Keep in mind that these keys are disposable and there is no threat when you lost them - just generate new ones.
Good randomness!