Thank you s7r! I think I'm going to start by simply using a mechanism similar to OnionBalance - I'm going to let Tor do its HS registration with a random HS name (and with a key that the host knows), then read the introduction points and keys and re-register them (a la OnionBalance) with a new HS name corresponding to the private key on the card. If I understand this correctly, this will make the hidden service accessible both on the random name and on the one the card knows the key to.

This way I don't have to modify Tor at all - I just let it do its thing, then re-register out of band, like OnionBalance does. I just do it from the same host instead of a frontend machine and I do it by signing with the smartcard key (and generating the name based on that).

Thanks again,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Sun, Oct 18, 2015 at 3:31 AM, s7r <s7r@sky-ip.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Razvan,

What you try to achieve is possible. It can be done, but requires code
to be written. If you are really interested about this feature you can
either sponsor someone to write the code for it either code it yourself.

The 1024 bit RSA private key (hidden service key) hosted in
HiddenServiceDir private_key file is used ONLY to sign descriptors
containing the introduction points for that hidden service. The signed
descriptors are then uploaded to the HSDirs responsible for that
hidden service at that time. Nothing more. This hidden service key has
nothing to do with the encrypted packets sent to that hidden service,
that is something different which is unrelated to the topic.

Here is how this could be done, in a very short example (10000 feet
overview):

1. Create a smartcard with your security parameters (password
protected or not, etc.), which can hold an encrypted 1024 bit RSA
private key and sign with it when requested.

2. Code Tor so that it can do the following:

2.1 - Can start without a private_key file in HiddenServiceDir, only
with a known hostname without exiting with fatal error. Currently, if
HiddenServiceDir is set, it won't start without this key and it will
create a new key there is none. A torrc setting like
'OfflineHiddenServiceKey 1' would make sense so Tor will know it needs
to behave differently when enabled. It will be 0 by default.

2.2 - Can normally choose and rotate introduction points as it wants
or needs to, but instead of signing the descriptors itself and
publishing them, just send the generated and unsigned descriptors via
ControlPort to another application or script.

2.3 - A separate application / script will take the unsigned
descriptors from Tor's ControlPort, access the smartcard, sign the
descriptors and return them to the Tor process the same - using
ControlPort, so that they can be published to the HSDirs. Make sure
the signing standard is respected as per Tor's specifications (bits,
encoding, format, etc.).

Easy to say, probably not so easy to implement. It will require a
proposal, code, some additional control port commands, probably other
stuff as well, but it is possible.

You can host the Tor instance handling the hidden service on another
server and do a VPN or SSH tunnel between that server and the server
having physical access to the smartcard, so they can talk to the
ControlPort as described above. Or you can connect the both servers
via other hidden services with authorization required so that each
servers remains anonymously from the other. You can let your
imagination go wild here and do plenty of things ...

Hope this helps.


On 10/18/2015 12:43 AM, Razvan Dragomirescu wrote:
> Ivan, according to
> https://www.torproject.org/docs/hidden-services.html.en (maybe I
> misunderstood it), at Step 4, the client sends an _encrypted_
> packet to the hidden service, so the hidden service needs to be
> able to decrypt that packet. So the key on the card needs to be
> used both for signing the HS registration and for decrypting the
> packets during the initial handshake, isn't this correct?
>
> As far as I could tell, there is no way to tell Tor to use a
> smartcard in any phase of the protocol, your OnionBalance tool
> simply handles the registration by itself (outside of Tor).
>
> Regarding bandwidth, this is for an Internet of Things project,
> there's very little data going back and forth, I only plan to use
> the Tor network because it's a very good way of establishing point
> to point circuits in a decentralized manner. The alternative would
> be to use something like PubNub  or Amazon's new IoT service, but
> those would depend on PubNub/Amazon.
>
> Razvan
>
> -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics
> SRL
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWIuhVAAoJEIN/pSyBJlsR65MIAIvtJWhU2eJTTgkadYuJxtyj
6of4hpPCI7R9WBdcaIE/Z3fKSzdOqcLKgeHyge6WlKNmNZE+hmzzwMl4aK4DywVW
gHdtI0I0sYd95plbAPWCT+ViZra5dsW50avbRMMgQ7jntihpZxziHKePviKd8Ps6
G8U/XeCDtz60MCI9EK+BlL2ufoK2f1VH7GEIWY5DcsLpOb41w+Mr/jSoH1vZVaQz
KuTGB5xsZte+GCd1prYKszzZeRLdjFaInrXO0f0dza/UCaZMQfJuCDCQoksPQn26
szolqTqFcbcWUaBDjvEwuR5p3Og3CU+weJJyETP0OAx++Rd28oy75IpkJLnhQms=
=0vbe
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev