Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Razvan Dragomirescu:
> Hey Evan, your hidden service appears to be down. Are there any mirrors of
> the code or can you bring it back online? My project is starting to take
> shape (took your advice and I'm using OpenPGP for now - may move to my own
> implementation in the future, but I want to create a small MVP ASAP).

Oops, should be fixed now. Thanks for noticing.

P.S. Please use direct email for such kind of issues to not to litter
the list.

--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Hey Evan, your hidden service appears to be down. Are there any mirrors of
the code or can you bring it back online? My project is starting to take
shape (took your advice and I'm using OpenPGP for now - may move to my own
implementation in the future, but I want to create a small MVP ASAP).

Thanks,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL





On Mon, May 23, 2016 at 11:25 PM, Evan Margin  wrote:

> Hey Razvan and tor-dev@!
>
> Razvan Dragomirescu:
> > I wanted to revisit this subject and actually start writing some
> > code, but it looks like Ivan Markin's GitHub account is gone,
> > together with all the code there. Ivan, are your modifications to
> > OnionBalance still available anywhere?
>
> Thanks for your interest!
>
> Yeap, GitHub told me someday that I'm blocked because of my
> suspiciousness. Since then I moved my repos to a lil' cgit box that is
> available over the onions [1].
>
>
> So the code you're looking for is at `keycity` branch at [2]. Also you
> need to fetch a pythonic package called `keycity` from [3]. Basically
> `keycity` is a kind of abstraction to use keys from
> keyfiles/smartcards/whatever in the same manner. It depends on `pyscard`
> for SW codes handling and as a `pcscd` bindings. It also can use
> `scdaemon` from GnuPG if you don't want to use `pcsc-lite` for some reason.
>
> Please note that this version of OnionBalance uses different config
> layout and other incompatibilities I can't recall. Also note that
> despite the fact that smartcard support works fine for me it may not do
> the same for you.
> For me Python packaging is a total mess with TMF (Too Many Files) as
> well as scripts/interpreter themselves. TMF makes everything to be
> really slow on machines running from flash cards (USB sticks, or BBB,
> Raspberry Pi, Soekris). This led me to develop `avant` [4][5] to which
> I'm going to add smartcard support someday soon (when there will be free
> software Go bindings for `pcsc-lite` that is not GPL'ed).
> So I want to say that my OnionBalance fork is not maintained and will
> not be. But I can help you out if you have troubles with crafting
> the installation of it.
>
> [1] http://hartwellnogoegst.onion/
> [2] http://hartwellnogoegst.onion/onionbalance
> [3] http://hartwellnogoegst.onion/keycity-py
> [4] http://hartwellnogoegst.onion/avant
> [5]
> https://lists.torproject.org/pipermail/tor-onions/2016-April/000132.html
>
> --
> Happy hacking!
> Ivan Markin
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Razvan Dragomirescu:
> Thanks Evan for the .onion links, I'll take a look. I'm still collecting
> data, testing hardware, etc. BTW, one of the cheapest options for this is
> http://www.ftsafe.com/product/epass/eJavaToken - $12 at
> http://javacardos.com/store/smartcard_eJavaToken.php . Unfortunately it has
> a bug that prevents OpenPGP from running (something to do with signature
> padding, I didn't look much into it). My plan is to write a very small
> JavaCard-based applet to load onto the card - that only does RSA key
> generation and signing, nothing else. Easy to write and easy to audit.

You can write it yourself but a working solution is already there. It's
possible to flash Java applet to almost any common jcard (they're pretty
cheap). Have a look at the nice guide by Subgraph team [1].
For the purpose of digest signing you can easily modify the applet to
have more than two signing keys (keep in mind that there are some card
limits).


[1] https://subgraph.com/sgos/documentation/smartcards/index.en.html
--
Have fun,
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Thank you Evan, Donncha,

Regarding 1024-bit RSA support, take a look at
http://www.fi.muni.cz/~xsvenda/jcsupport.html - almost all JavaCard cards
support that.

I'm a Java developer but it looks like I'm going to have to switch to (and
learn) Python for this since almost all Tor utilities appear to only be
maintained in Python (and I don't feel like reinventing the wheel in Java).
We'll see...

Thanks Evan for the .onion links, I'll take a look. I'm still collecting
data, testing hardware, etc. BTW, one of the cheapest options for this is
http://www.ftsafe.com/product/epass/eJavaToken - $12 at
http://javacardos.com/store/smartcard_eJavaToken.php . Unfortunately it has
a bug that prevents OpenPGP from running (something to do with signature
padding, I didn't look much into it). My plan is to write a very small
JavaCard-based applet to load onto the card - that only does RSA key
generation and signing, nothing else. Easy to write and easy to audit.

Thanks again,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Mon, May 23, 2016 at 11:26 PM, Evan Margin  wrote:

> Hello Donncha!
>
> Donncha Ó Cearbhaill:
> > However his code was integrating with a smartcard at a very low
> > level by sending AT commands manually. I don't think that is the
> > best approach for compatibility.
> >
> > I think a better way would be to interface with the tokens via the
> > PKCS#11 protocol. The majority of smartcards and HSMs implement this
> >  standard and there are compatible implementations available for most
> >  operating systems. The Python pykcs11 module should be a helpful
> > start [1].
>
> Yeah, interfacing smartcard directly or via GnuPG scdaemon is not the
> best approach. But PKCS#11 in even worse. Much much worse. This standard
> is so huge that noone can implement it right. It raises enterance
> threshold so high that it will be used only by overproprietary entities.
> OpenPGP Card spec is pretty small so that everyone can write code within
> an hour and start to interface with a card. So did I. At least I know
> what's going on under the hood and these transparency and simplicity
> makes this setup more secure.
>
> --
> Ivan Markin
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Evan Margin]

Hello Donncha!

Donncha Ó Cearbhaill:
> However his code was integrating with a smartcard at a very low
> level by sending AT commands manually. I don't think that is the
> best approach for compatibility.
> 
> I think a better way would be to interface with the tokens via the 
> PKCS#11 protocol. The majority of smartcards and HSMs implement this
>  standard and there are compatible implementations available for most
>  operating systems. The Python pykcs11 module should be a helpful 
> start [1].

Yeah, interfacing smartcard directly or via GnuPG scdaemon is not the
best approach. But PKCS#11 in even worse. Much much worse. This standard
is so huge that noone can implement it right. It raises enterance
threshold so high that it will be used only by overproprietary entities.
OpenPGP Card spec is pretty small so that everyone can write code within
an hour and start to interface with a card. So did I. At least I know
what's going on under the hood and these transparency and simplicity
makes this setup more secure.

--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Evan Margin]

Hey Razvan and tor-dev@!

Razvan Dragomirescu:
> I wanted to revisit this subject and actually start writing some 
> code, but it looks like Ivan Markin's GitHub account is gone, 
> together with all the code there. Ivan, are your modifications to 
> OnionBalance still available anywhere?

Thanks for your interest!

Yeap, GitHub told me someday that I'm blocked because of my
suspiciousness. Since then I moved my repos to a lil' cgit box that is
available over the onions [1].


So the code you're looking for is at `keycity` branch at [2]. Also you
need to fetch a pythonic package called `keycity` from [3]. Basically
`keycity` is a kind of abstraction to use keys from
keyfiles/smartcards/whatever in the same manner. It depends on `pyscard`
for SW codes handling and as a `pcscd` bindings. It also can use
`scdaemon` from GnuPG if you don't want to use `pcsc-lite` for some reason.

Please note that this version of OnionBalance uses different config
layout and other incompatibilities I can't recall. Also note that
despite the fact that smartcard support works fine for me it may not do
the same for you.
For me Python packaging is a total mess with TMF (Too Many Files) as
well as scripts/interpreter themselves. TMF makes everything to be
really slow on machines running from flash cards (USB sticks, or BBB,
Raspberry Pi, Soekris). This led me to develop `avant` [4][5] to which
I'm going to add smartcard support someday soon (when there will be free
software Go bindings for `pcsc-lite` that is not GPL'ed).
So I want to say that my OnionBalance fork is not maintained and will
not be. But I can help you out if you have troubles with crafting
the installation of it.

[1] http://hartwellnogoegst.onion/
[2] http://hartwellnogoegst.onion/onionbalance
[3] http://hartwellnogoegst.onion/keycity-py
[4] http://hartwellnogoegst.onion/avant
[5] https://lists.torproject.org/pipermail/tor-onions/2016-April/000132.html

--
Happy hacking!
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Donncha Ó Cearbhaill]

Razvan Dragomirescu:
> Hello again,
> 
> I wanted to revisit this subject and actually start writing some code, but
> it looks like Ivan Markin's GitHub account is gone, together with all the
> code there. Ivan, are your modifications to OnionBalance still available
> anywhere?
> 
> Thank you,
> Razvan
> 

Hi Razvan,

I'm the author of OnionBalance, I'm glad to hear that your interested in
implementing smartcard support. It's something that I've wanted to
implement but I haven't got around to it yet.

Unfortunately I don't have a local copy of Ivan's branch. However his
code was integrating with a smartcard at a very low level by sending AT
commands manually. I don't think that is the best approach for
compatibility.

I think a better way would be to interface with the tokens via the
PKCS#11 protocol. The majority of smartcards and HSMs implement this
standard and there are compatible implementations available for most
operating systems. The Python pykcs11 module should be a helpful start [1].

I'm imagining a config file option where a user can specify a service
key as either a file path or a PKCS#11 URI [2].

A few months ago I researched which common smartcards are compatible
with the 1024 bit RSA private keys. It looks like some low cost options
such as the Yubikey 4 now only support 2048 bit and longer keys. It
would be great if someone can find out which hardware we can use with
102 bit hidden service keys!

Let me know if you have any questions. I'm happy to help you implement
this and get it merged.

Regards,
Donncha


[1] https://pypi.python.org/pypi/pykcs11
[2] https://tools.ietf.org/html/rfc7512



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Virgil Griffith]

This may be not quite what you want, but the Estonia E-resident card
supports basic crypto with the private key on the smart card---i.e.,
you have to physically have the card to be able to read the encrypted
mail.

There are probably more elegant solutions than plugging into the
Estonia E-resident framework, but you'll get press for using the
E-resident card---the Estonians always get happy when someone uses
their card for something novel.  Which might be a perk.

Note: I believe that, theoretically, yes, the Estonian government
could jot down your private key before it goes onto the card.  But
they are economically disincentivized from doing that.

-V

On Wed, Oct 14, 2015 at 4:08 AM, Razvan Dragomirescu
 wrote:
> Hello,
>
> I am not sure if this has been discussed before or how hard it would be to
> implement, but I'm looking for a way to integrate a smartcard with Tor -
> essentially, I want to be able to host hidden service keys on the card. I'm
> trying to bind the hidden service to a hardware component (the smartcard) so
> that it can be securely hosted in a hostile environment as well as
> impossible to clone/move without physical access to the smartcard.
>
> I have Tor running on the USBArmory by InversePath (
> http://inversepath.com/usbarmory.html ) and have a microSD form factor card
> made by Swissbit (
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> ) up and running on it. I am a JavaCard developer myself  and I have
> developed embedded Linux firmwares before but I have never touched the Tor
> source.
>
> Is there anyone that is willing to take on a side project doing this? Would
> it be just a matter of configuring OpenSSL to use the card (I haven't tried
> that yet)?
>
> Thank you,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Hello again,

I wanted to revisit this subject and actually start writing some code, but
it looks like Ivan Markin's GitHub account is gone, together with all the
code there. Ivan, are your modifications to OnionBalance still available
anywhere?

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Tue, Oct 20, 2015 at 10:05 PM, Ivan Markin  wrote:

> grarpamp:
> > Yes if you intend to patch tor to use a smartcard as a
> > cryptographic coprocessor offloading anything of interest
> > that needs signed / encrypted / decrypted to it. The card
> > will need to remain plugged in for tor to function.
>
> As I said before, only thing that actually needs to be protected here is
> "main"/"frontend" .onion identity. For that purpose all you need to do
> is to sign descriptors. And not to lose the key.
>
> grarpamp:
> > However how is "pin" on swissbit enabled?
> > If it goes from the host (say via ssh or keyboard or some
> > device or app) through usb port through armory to swissbit,
> > that is never secure.
>
> No, I will be secure. An adversary could sniff your PIN and sign
> whatever they want to, true. But revealing the PIN != revealing the key.
> In this case your identity key is still safe even if your PIN is
> "compromised".
>
> --
> Ivan Markin
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Yes, that's precisely the point - if the card is stolen, the service is
stolen with it. I'm not trying to prevent that, I'm trying to _tie_ the
service to the card - whoever has the card runs the service. If you see
that the card is gone, you know your service is gone too. If the card is
still there, your service keys are safe.

Razvan

On Tue, Oct 20, 2015 at 10:59 PM, grarpamp  wrote:

> On Tue, Oct 20, 2015 at 3:05 PM, Ivan Markin  wrote:
> > No, I will be secure. An adversary could sniff your PIN and sign
> > whatever they want to, true. But revealing the PIN != revealing the key.
> > In this case your identity key is still safe even if your PIN is
> > "compromised".
>
> Yes the private key may be safe, but the smartcard may be stolen or
> removed from your sphere of access and reutilized with the sniffed
> pin, thus your onion or relay or node is no longer under your control,
> which was the point of the project. The enablement of the smartcard
> needs to be out of band, or use some strong one way challenge
> response like pki/totp/hotp/skey/opie.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[grarpamp]

On Tue, Oct 20, 2015 at 3:05 PM, Ivan Markin  wrote:
> No, I will be secure. An adversary could sniff your PIN and sign
> whatever they want to, true. But revealing the PIN != revealing the key.
> In this case your identity key is still safe even if your PIN is
> "compromised".

Yes the private key may be safe, but the smartcard may be stolen or
removed from your sphere of access and reutilized with the sniffed
pin, thus your onion or relay or node is no longer under your control,
which was the point of the project. The enablement of the smartcard
needs to be out of band, or use some strong one way challenge
response like pki/totp/hotp/skey/opie.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

grarpamp:
> Yes if you intend to patch tor to use a smartcard as a
> cryptographic coprocessor offloading anything of interest
> that needs signed / encrypted / decrypted to it. The card
> will need to remain plugged in for tor to function.

As I said before, only thing that actually needs to be protected here is
"main"/"frontend" .onion identity. For that purpose all you need to do
is to sign descriptors. And not to lose the key.

grarpamp:
> However how is "pin" on swissbit enabled?
> If it goes from the host (say via ssh or keyboard or some
> device or app) through usb port through armory to swissbit,
> that is never secure.

No, I will be secure. An adversary could sniff your PIN and sign
whatever they want to, true. But revealing the PIN != revealing the key.
In this case your identity key is still safe even if your PIN is
"compromised".

-- 
Ivan Markin



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[grarpamp]

You mentione...

> I have Tor running on the USBArmory by InversePath (
> http://inversepath.com/usbarmory.html ) and have a microSD form factor card
> made by Swissbit (
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> ) up and running on it.

Good that USBarmory could provide even tor binaries
over a usb mass storage fs for the host to run.
Or even run the tor process and network itself as you say.

However how is "pin" on swissbit enabled?
If it goes from the host (say via ssh or keyboard or some
device or app) through usb port through armory to swissbit,
that is never secure.
If it goes from external pad through GPIO on armory
to swissbit, that will not be secure if host can in
any way snoop on armory, or can use or modify code
on the armory to do that and report the armory core / bus
data back to the host.
If swissbit card itself had external I/O for "pin" ops,
that would be secure.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[grarpamp]

On Sat, Oct 17, 2015 at 5:46 PM, Razvan Dragomirescu
 wrote:
> Exactly, you ask the smartcard to decrypt your traffic (and sign data if
> needed), it never tells you the key, it's a blackbox - it gets plaintext
> input and gives you encrypted (or signed) output, without ever revealing the
> key it's used. It can also generate the key internally (actually a keypair,
> it stores the private key in secure memory (protected from software _and_
> hardware attacks)) and gives you the public key so that you can publish it.
>
> Remember, smartcards are not just storage, they are tamper resistant
> embedded computers.

I misread your original intent.

Yes if you intend to patch tor to use a smartcard as a
cryptographic coprocessor offloading anything of interest
that needs signed / encrypted / decrypted to it. The card
will need to remain plugged in for tor to function. The card
will need to know to generate new keys periodically for
the functions in tor that need them... new key usage API's
will need developed between the card and tor to manage that.
OpenSSL may have card functions already but not in a way
that makes sense to abstract upper program logic of tor.
And your own use of "pin" and input to enable the card
itself should be as secure as that to be protected.

It's worth looking at the keyops per second and
streamrates per second needed by various crypto
parts of tor and determining what smartcards / expansion
cards on the market could handle which parts of that.
Cards need to support the crypto algos that tor uses
or will be moving to.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Razvan Dragomirescu:
> Ivan, if I understand
> https://onionbalance.readthedocs.org/en/latest/design.html#next-generation-onion-services-prop-224-compatibility
> correctly, the setup I've planned will no longer work once Tor switches to
> the next generation hidden services architecture, is this correct? Will
> there be any backwards compatibility or will old hidden services simply
> stop working at that point?

No, actually the setup will work. But it will not work until the code
base (of the OB) is changed*. For now one can sign arbitrary set of IPs
with their key (you can test it with  e.g. Facebook HS) and this
descriptor will be valid [1].
Cross-certifications are just a mechanism of hardening this process. In
order to make frontend descriptor valid backend instances must "be
aware" of the frontend. So backend nodes are certifying public key of
frontend and then they can be included into a frontend descriptor.
[using OB terminology]

[*] Also there is still only RSA crypto in the OB.

[1] https://trac.torproject.org/projects/tor/ticket/15951
-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

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!
-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Ivan, if I understand
https://onionbalance.readthedocs.org/en/latest/design.html#next-generation-onion-services-prop-224-compatibility
correctly, the setup I've planned will no longer work once Tor switches to
the next generation hidden services architecture, is this correct? Will
there be any backwards compatibility or will old hidden services simply
stop working at that point?

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Sun, Oct 18, 2015 at 12:08 PM, Razvan Dragomirescu <
razvan.dragomire...@veri.fi> wrote:

> Thank you Ivan!
>
> On Sun, Oct 18, 2015 at 1:44 AM, Ivan Markin  wrote:
>
>> Not exactly. The trick is that keys are not the same. For more details
>> have a look at the specifications [1]. There is a "permanent key"
>> ("holds the name", signs descriptors) and an "onion key" [2] for each
>> Introduction Point to communicate with the HS. So the "nameholder" key
>> ("permanent") is used only for signing descriptor with a list of IPs and
>> corresponding keys.
>>
>>
> 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).
>
>
>> > 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.
>>
>>
>
>
>> 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.
>
>  Thanks again!
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

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  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 (1 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/pSyBJlsR65MIAIvtJWhU2eJTT

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Thank you Ivan!

On Sun, Oct 18, 2015 at 1:44 AM, Ivan Markin  wrote:

> Not exactly. The trick is that keys are not the same. For more details
> have a look at the specifications [1]. There is a "permanent key"
> ("holds the name", signs descriptors) and an "onion key" [2] for each
> Introduction Point to communicate with the HS. So the "nameholder" key
> ("permanent") is used only for signing descriptor with a list of IPs and
> corresponding keys.
>
>
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).


> > 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.
>
>


> 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.

 Thanks again!
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[s7r]

-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 (1 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

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Razvan Dragomirescu:
> 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?

Not exactly. The trick is that keys are not the same. For more details
have a look at the specifications [1]. There is a "permanent key"
("holds the name", signs descriptors) and an "onion key" [2] for each
Introduction Point to communicate with the HS. So the "nameholder" key
("permanent") is used only for signing descriptor with a list of IPs and
corresponding keys.

> 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).

Yes, there is no support for SCs in little-t-tor itself.
What OB is doing is just a combining some IPs (from backend instances)
into frontend instance descriptor, signing it and then publishing it via
tor.

btw, OnionBalace is not my project [3].

> 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.

As I said before it may not fit your purpose. :) I still don't think
that decrypting via SC is necessary. If somebody already knows your
backend keys then certainly they know any of your data on this machine.
Maybe I missed something.


[1] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n63
[2] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n364
[3] https://github.com/donnchac/onionbalance
-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Exactly, you ask the smartcard to decrypt your traffic (and sign data if
needed), it never tells you the key, it's a blackbox - it gets plaintext
input and gives you encrypted (or signed) output, without ever revealing
the key it's used. It can also generate the key internally (actually a
keypair, it stores the private key in secure memory (protected from
software _and_ hardware attacks)) and gives you the public key so that you
can publish it.

Remember, smartcards are not just storage, they are tamper resistant
embedded computers. Very limited computers, true, but very good at keeping
secret keys secret, both from a software attack and from a hardware (drop
the card in acid, use a logic analyzer kind of) attack.

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Sat, Oct 17, 2015 at 11:40 PM, Ivan Markin  wrote:

> Ken Keys:
> >> > The point is that one can't[*] extract a private key from a smartcard
> >> > and because of that even if machine is compromised your private key
> >> > stays safe.
> > If the machine is going to use the HS key, the actual HS key has to be
> > visible to it.
>
> Nope. If the machine is going to use the HS key it can ask a smartcard
> to do so. Of course private key is visible to something/someone anyway.
> But in case of smartcards it is visible to a smartcard only.
>
> > An encrypted container holding a VM could use RSA-style
> > public/private key encryption so that it never has to see the private
> > key used to unlock it. You would still need to trust the VM, but the
> > encrypted container would allow you to establish a chain of custody.
>
> It's OK to unlock some encrypted block device/VM with some 'unpluggable'
> key. But it does nothing to protect your HS' identity.
>
> --
> Ivan Markin
> /"\
> \ /   ASCII Ribbon Campaign
>  Xagainst HTML email & Microsoft
> / \  attachments! http://arc.pasp.de/
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

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

On Sat, Oct 17, 2015 at 10:13 PM, Ivan Markin  wrote:

> Razvan Dragomirescu:
> > Thank you Ivan, I've taken a look but as far as I understand your project
> > only signs the HiddenService descriptors from an OpenPGP card. It still
> > requires each backend instance to have its own copy of the key (where it
> > can be read by an attacker). My goal is to have the HS private key
> > exclusively inside the smartcard and only sign/decrypt with it when
> needed
> > but never reveal it.An attacker should not be able to steal the key and
> > host his own HS at the same address - the address would be effectively
> tied
> > to the smartcard - whoever owns the smartcard can sign HS descriptors and
> > decrypt traffic with it, so he or she is the owner of the service.
>
> Yes, it still requires to have plain keys for decryption of traffic on
> backend instances, sure. But you're not right about key "stealing"
> (copying). An address of a HS is calculated from key which is signing
> descriptors. This key resides on a smartcard. It's already
> "the-address-would-be-effectively-tied-to-the-smartcard" situation there.
>
> I do not see any reason to decrypt traffic on a smartcard; in case if an
> attacker can copy your backend key there is no need to decrypt anything
> - they already have an access to the content on your instance. Also
> backend instances' keys are disposable - you can change them seamlessly.
>
> P.S. Notice about bandwidth issue when you're decrypting all of the
> traffic on a smartcard (half-duplex, etc.).
>
> --
> Ivan Markin
> /"\
> \ /   ASCII Ribbon Campaign
>  Xagainst HTML email & Microsoft
> / \  attachments! http://arc.pasp.de/
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Ken Keys:
>> > The point is that one can't[*] extract a private key from a smartcard
>> > and because of that even if machine is compromised your private key
>> > stays safe.
> If the machine is going to use the HS key, the actual HS key has to be
> visible to it.

Nope. If the machine is going to use the HS key it can ask a smartcard
to do so. Of course private key is visible to something/someone anyway.
But in case of smartcards it is visible to a smartcard only.

> An encrypted container holding a VM could use RSA-style
> public/private key encryption so that it never has to see the private
> key used to unlock it. You would still need to trust the VM, but the
> encrypted container would allow you to establish a chain of custody.

It's OK to unlock some encrypted block device/VM with some 'unpluggable'
key. But it does nothing to protect your HS' identity.

-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ken Keys]

On 10/17/2015 12:27 PM, Ivan Markin wrote:
> Ken Keys:
>> If the tor process is going to use the key, at some point the
>> unencrypted key has to be visible to the machine running it. You would
>> in any case have to trust the machine hosting the tor node. A more
>> secure setup would be to run the tor node inside an encrypted VM and use
>> your smartcard/dongle/whatever to unlock the VM.
> The point is that one can't[*] extract a private key from a smartcard
> and because of that even if machine is compromised your private key
> stays safe.
>
>
> [*] Not so easy, but possible.
If the machine is going to use the HS key, the actual HS key has to be
visible to it. An encrypted container holding a VM could use RSA-style
public/private key encryption so that it never has to see the private
key used to unlock it. You would still need to trust the VM, but the
encrypted container would allow you to establish a chain of custody.


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Ken Keys:
> If the tor process is going to use the key, at some point the
> unencrypted key has to be visible to the machine running it. You would
> in any case have to trust the machine hosting the tor node. A more
> secure setup would be to run the tor node inside an encrypted VM and use
> your smartcard/dongle/whatever to unlock the VM.

The point is that one can't[*] extract a private key from a smartcard
and because of that even if machine is compromised your private key
stays safe.


[*] Not so easy, but possible.
-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ken Keys]

If the tor process is going to use the key, at some point the
unencrypted key has to be visible to the machine running it. You would
in any case have to trust the machine hosting the tor node. A more
secure setup would be to run the tor node inside an encrypted VM and use
your smartcard/dongle/whatever to unlock the VM.

On 10/17/2015 12:00 PM, Razvan Dragomirescu wrote:
> Tamper resistance. And the fact that an attacker with access to the
> machine running Tor can read your encrypted thumb drive (you need to
> decrypt it at some point to load the key into the Tor process since
> the encrypted thumbdrive doesn't run crypto algos internally). A
> smartcard is a small embedded tamper-resistant _computer_ - you never
> ask it for the key, you ask it to _decrypt_ something for you or
> _sign_ something for you, you can never extract the key out of the card.
>
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
>
> On Sat, Oct 17, 2015 at 9:36 PM, Ken Keys  > wrote:
>
> What is the advantage of a smart card over a standard encrypted
> thumb drive?
>

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Razvan Dragomirescu:
> Thank you Ivan, I've taken a look but as far as I understand your project
> only signs the HiddenService descriptors from an OpenPGP card. It still
> requires each backend instance to have its own copy of the key (where it
> can be read by an attacker). My goal is to have the HS private key
> exclusively inside the smartcard and only sign/decrypt with it when needed
> but never reveal it.An attacker should not be able to steal the key and
> host his own HS at the same address - the address would be effectively tied
> to the smartcard - whoever owns the smartcard can sign HS descriptors and
> decrypt traffic with it, so he or she is the owner of the service.

Yes, it still requires to have plain keys for decryption of traffic on
backend instances, sure. But you're not right about key "stealing"
(copying). An address of a HS is calculated from key which is signing
descriptors. This key resides on a smartcard. It's already
"the-address-would-be-effectively-tied-to-the-smartcard" situation there.

I do not see any reason to decrypt traffic on a smartcard; in case if an
attacker can copy your backend key there is no need to decrypt anything
- they already have an access to the content on your instance. Also
backend instances' keys are disposable - you can change them seamlessly.

P.S. Notice about bandwidth issue when you're decrypting all of the
traffic on a smartcard (half-duplex, etc.).

-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Tamper resistance. And the fact that an attacker with access to the machine
running Tor can read your encrypted thumb drive (you need to decrypt it at
some point to load the key into the Tor process since the encrypted
thumbdrive doesn't run crypto algos internally). A smartcard is a small
embedded tamper-resistant _computer_ - you never ask it for the key, you
ask it to _decrypt_ something for you or _sign_ something for you, you can
never extract the key out of the card.

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL


On Sat, Oct 17, 2015 at 9:36 PM, Ken Keys  wrote:

> What is the advantage of a smart card over a standard encrypted thumb
> drive?
>
> On 10/17/2015 11:19 AM, Razvan Dragomirescu wrote:
> > Thank you Ivan, I've taken a look but as far as I understand your
> > project only signs the HiddenService descriptors from an OpenPGP card.
> > It still requires each backend instance to have its own copy of the
> > key (where it can be read by an attacker). My goal is to have the HS
> > private key exclusively inside the smartcard and only sign/decrypt
> > with it when needed but never reveal it. An attacker should not be
> > able to steal the key and host his own HS at the same address - the
> > address would be effectively tied to the smartcard - whoever owns the
> > smartcard can sign HS descriptors and decrypt traffic with it, so he
> > or she is the owner of the service.
> >
> > Best regards,
> > Razvan
> >
> > --
> > Razvan Dragomirescu
> > Chief Technology Officer
> > Cayenne Graphics SRL
> >
> > On Sat, Oct 17, 2015 at 4:43 AM, Ivan Markin  > > wrote:
> >
> > Hello,
> > Razvan Dragomirescu:
> > > I am not sure if this has been discussed before or how hard it
> would be to
> > > implement, but I'm looking for a way to integrate a smartcard
> > with Tor -
> > > essentially, I want to be able to host hidden service keys on
> > the card. I'm
> > > trying to bind the hidden service to a hardware component (the
> > smartcard)
> > > so that it can be securely hosted in a hostile environment as
> > well as
> > > impossible to clone/move without physical access to the smartcard.
> >
> > I'm not sure that this solution is 100% for your purposes. But
> > recently
> > I've added OpenPGP smartcard support to do exactly this into
> > OnionBlance
> > [1]+[2]. What it does is that it just signs a HS descriptor using
> > OpenPGP SC (via 'Signature' or 'Authentication' key). [It's still a
> > pretty dirty hack, there is no even any exception handling.] You
> > can use
> > it by installing "manager/front" service with your smartcard in it
> via
> > OnionBalace and balancing to your actual HS. There is no any
> bandwidth
> > limiting (see OnionBalance design). You can setup OB and an actual
> > HS on
> > the same machine for sure.
> >
> > > I have Tor running on the USBArmory by InversePath (
> > > http://inversepath.com/usbarmory.html ) and have a microSD form
> > factor card
> > > made by Swissbit (
> > >
> >
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> > <
> http://www.swissbit.com/products/security-products/overwiev/security-products-overview/
> >
> > > ) up and running on it. I am a JavaCard developer myself  and I
> have
> > > developed embedded Linux firmwares before but I have never
> > touched the Tor
> > > source.
> >
> > There is a nice JavaC applet by Joeri [3]. It's the same applet that
> > Yubikey is using. You can find well-written tutorial of producing
> your
> > OpenPGP card at Subgraph [4].
> >
> > >
> > > Is there anyone that is willing to take on a side project doing
> > this? Would
> > > it be just a matter of configuring OpenSSL to use the card (I
> > haven't tried
> > > that yet)?
> >
> > I'm not sure that it is worth to implement a card support in
> > little-t-tor itself. As I said, all the logic is about HS descriptor
> > signing. Python and other langs that provide readablity will provide
> > security then.
> > I think/hope so.
> >
> > [1] https://github.com/mark-in/onionbalance
> > [2] https://github.com/mark-in/openpgpycard
> > [3] http://sourceforge.net/projects/javacardopenpgp/
> > [4] https://subgraph.com/sgos/documentation/smartcards/index.en.html
> >
> > Hope it helps.
> > --
> > Ivan Markin
> > /"\
> > \ /   ASCII Ribbon Campaign
> >  Xagainst HTML email & Microsoft
> > / \  attachments! http://arc.pasp.de/
> >
> >
> > ___
> > tor-dev mailing list
> > tor-dev@lists.torproject.org 
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
> >
> >
> >
> > ___
> > tor-dev mailing list
> > tor-de

Re: [tor-dev] adding smartcard support to Tor

[Ken Keys]

What is the advantage of a smart card over a standard encrypted thumb drive?

On 10/17/2015 11:19 AM, Razvan Dragomirescu wrote:
> Thank you Ivan, I've taken a look but as far as I understand your
> project only signs the HiddenService descriptors from an OpenPGP card.
> It still requires each backend instance to have its own copy of the
> key (where it can be read by an attacker). My goal is to have the HS
> private key exclusively inside the smartcard and only sign/decrypt
> with it when needed but never reveal it. An attacker should not be
> able to steal the key and host his own HS at the same address - the
> address would be effectively tied to the smartcard - whoever owns the
> smartcard can sign HS descriptors and decrypt traffic with it, so he
> or she is the owner of the service.
>
> Best regards,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
> On Sat, Oct 17, 2015 at 4:43 AM, Ivan Markin  > wrote:
>
> Hello,
> Razvan Dragomirescu:
> > I am not sure if this has been discussed before or how hard it would be 
> to
> > implement, but I'm looking for a way to integrate a smartcard
> with Tor -
> > essentially, I want to be able to host hidden service keys on
> the card. I'm
> > trying to bind the hidden service to a hardware component (the
> smartcard)
> > so that it can be securely hosted in a hostile environment as
> well as
> > impossible to clone/move without physical access to the smartcard.
>
> I'm not sure that this solution is 100% for your purposes. But
> recently
> I've added OpenPGP smartcard support to do exactly this into
> OnionBlance
> [1]+[2]. What it does is that it just signs a HS descriptor using
> OpenPGP SC (via 'Signature' or 'Authentication' key). [It's still a
> pretty dirty hack, there is no even any exception handling.] You
> can use
> it by installing "manager/front" service with your smartcard in it via
> OnionBalace and balancing to your actual HS. There is no any bandwidth
> limiting (see OnionBalance design). You can setup OB and an actual
> HS on
> the same machine for sure.
>
> > I have Tor running on the USBArmory by InversePath (
> > http://inversepath.com/usbarmory.html ) and have a microSD form
> factor card
> > made by Swissbit (
> >
> 
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> 
> 
> > ) up and running on it. I am a JavaCard developer myself  and I have
> > developed embedded Linux firmwares before but I have never
> touched the Tor
> > source.
>
> There is a nice JavaC applet by Joeri [3]. It's the same applet that
> Yubikey is using. You can find well-written tutorial of producing your
> OpenPGP card at Subgraph [4].
>
> >
> > Is there anyone that is willing to take on a side project doing
> this? Would
> > it be just a matter of configuring OpenSSL to use the card (I
> haven't tried
> > that yet)?
>
> I'm not sure that it is worth to implement a card support in
> little-t-tor itself. As I said, all the logic is about HS descriptor
> signing. Python and other langs that provide readablity will provide
> security then.
> I think/hope so.
>
> [1] https://github.com/mark-in/onionbalance
> [2] https://github.com/mark-in/openpgpycard
> [3] http://sourceforge.net/projects/javacardopenpgp/
> [4] https://subgraph.com/sgos/documentation/smartcards/index.en.html
>
> Hope it helps.
> --
> Ivan Markin
> /"\
> \ /   ASCII Ribbon Campaign
>  Xagainst HTML email & Microsoft
> / \  attachments! http://arc.pasp.de/
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Thank you Ivan, I've taken a look but as far as I understand your project
only signs the HiddenService descriptors from an OpenPGP card. It still
requires each backend instance to have its own copy of the key (where it
can be read by an attacker). My goal is to have the HS private key
exclusively inside the smartcard and only sign/decrypt with it when needed
but never reveal it. An attacker should not be able to steal the key and
host his own HS at the same address - the address would be effectively tied
to the smartcard - whoever owns the smartcard can sign HS descriptors and
decrypt traffic with it, so he or she is the owner of the service.

Best regards,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Sat, Oct 17, 2015 at 4:43 AM, Ivan Markin  wrote:

> Hello,
> Razvan Dragomirescu:
> > I am not sure if this has been discussed before or how hard it would be
> to
> > implement, but I'm looking for a way to integrate a smartcard with Tor -
> > essentially, I want to be able to host hidden service keys on the card.
> I'm
> > trying to bind the hidden service to a hardware component (the smartcard)
> > so that it can be securely hosted in a hostile environment as well as
> > impossible to clone/move without physical access to the smartcard.
>
> I'm not sure that this solution is 100% for your purposes. But recently
> I've added OpenPGP smartcard support to do exactly this into OnionBlance
> [1]+[2]. What it does is that it just signs a HS descriptor using
> OpenPGP SC (via 'Signature' or 'Authentication' key). [It's still a
> pretty dirty hack, there is no even any exception handling.] You can use
> it by installing "manager/front" service with your smartcard in it via
> OnionBalace and balancing to your actual HS. There is no any bandwidth
> limiting (see OnionBalance design). You can setup OB and an actual HS on
> the same machine for sure.
>
> > I have Tor running on the USBArmory by InversePath (
> > http://inversepath.com/usbarmory.html ) and have a microSD form factor
> card
> > made by Swissbit (
> >
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> > ) up and running on it. I am a JavaCard developer myself  and I have
> > developed embedded Linux firmwares before but I have never touched the
> Tor
> > source.
>
> There is a nice JavaC applet by Joeri [3]. It's the same applet that
> Yubikey is using. You can find well-written tutorial of producing your
> OpenPGP card at Subgraph [4].
>
> >
> > Is there anyone that is willing to take on a side project doing this?
> Would
> > it be just a matter of configuring OpenSSL to use the card (I haven't
> tried
> > that yet)?
>
> I'm not sure that it is worth to implement a card support in
> little-t-tor itself. As I said, all the logic is about HS descriptor
> signing. Python and other langs that provide readablity will provide
> security then.
> I think/hope so.
>
> [1] https://github.com/mark-in/onionbalance
> [2] https://github.com/mark-in/openpgpycard
> [3] http://sourceforge.net/projects/javacardopenpgp/
> [4] https://subgraph.com/sgos/documentation/smartcards/index.en.html
>
> Hope it helps.
> --
> Ivan Markin
> /"\
> \ /   ASCII Ribbon Campaign
>  Xagainst HTML email & Microsoft
> / \  attachments! http://arc.pasp.de/
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Thank you grarpamp, but that's not what I'm trying to prevent/achieve. I
simply want to host the private key for a hidden service inside a secure
element (a smartcard) to ensure that only the hardware that has direct
access to my smartcard can publish the descriptors for the service and
decrypt incoming packets. I do realize the host will have complete control
over the Tor instance and that's fine, I simply want to prevent it (or a
different host) from ever publishing this HS without having access to the
smartcard.

The idea is to tie the HS to the physical smart card - whoever holds the
smartcard can publish the service, once the card is removed, the service
moves with it.

An attacker (with or without physical access to the machine running Tor)
would not be able to extract any information that would allow him to
impersonate the service at a later time. Of course, he can change the
_current_ content or serve his own, but cannot permanently compromise the
service by reading its private key.

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Fri, Oct 16, 2015 at 1:56 AM, grarpamp  wrote:

> On Tue, Oct 13, 2015 at 4:08 PM, Razvan Dragomirescu
>  wrote:
> > essentially, I want to be able to host hidden service keys on the card.
> I'm
> > trying to bind the hidden service to a hardware component (the
> smartcard) so
> > that it can be securely hosted in a hostile environment as well as
> > impossible to clone/move without physical access to the smartcard.
>
> The host will have both physical and logical access to your
> process space, therefore you're compromised regardless
> of where you physically keep the keys or how you acccess
> them.
>
> Though there are trac tickets you can search for involving
> loading keys into tor controller via remote tunnel without need
> to leave and mount or access physical devices in /dev.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[Ivan Markin]

Hello,
Razvan Dragomirescu:
> I am not sure if this has been discussed before or how hard it would be to
> implement, but I'm looking for a way to integrate a smartcard with Tor -
> essentially, I want to be able to host hidden service keys on the card. I'm
> trying to bind the hidden service to a hardware component (the smartcard)
> so that it can be securely hosted in a hostile environment as well as
> impossible to clone/move without physical access to the smartcard.

I'm not sure that this solution is 100% for your purposes. But recently
I've added OpenPGP smartcard support to do exactly this into OnionBlance
[1]+[2]. What it does is that it just signs a HS descriptor using
OpenPGP SC (via 'Signature' or 'Authentication' key). [It's still a
pretty dirty hack, there is no even any exception handling.] You can use
it by installing "manager/front" service with your smartcard in it via
OnionBalace and balancing to your actual HS. There is no any bandwidth
limiting (see OnionBalance design). You can setup OB and an actual HS on
the same machine for sure.

> I have Tor running on the USBArmory by InversePath (
> http://inversepath.com/usbarmory.html ) and have a microSD form factor card
> made by Swissbit (
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> ) up and running on it. I am a JavaCard developer myself  and I have
> developed embedded Linux firmwares before but I have never touched the Tor
> source.

There is a nice JavaC applet by Joeri [3]. It's the same applet that
Yubikey is using. You can find well-written tutorial of producing your
OpenPGP card at Subgraph [4].

> 
> Is there anyone that is willing to take on a side project doing this? Would
> it be just a matter of configuring OpenSSL to use the card (I haven't tried
> that yet)?

I'm not sure that it is worth to implement a card support in
little-t-tor itself. As I said, all the logic is about HS descriptor
signing. Python and other langs that provide readablity will provide
security then.
I think/hope so.

[1] https://github.com/mark-in/onionbalance
[2] https://github.com/mark-in/openpgpycard
[3] http://sourceforge.net/projects/javacardopenpgp/
[4] https://subgraph.com/sgos/documentation/smartcards/index.en.html

Hope it helps.
-- 
Ivan Markin
/"\
\ /   ASCII Ribbon Campaign
 Xagainst HTML email & Microsoft
/ \  attachments! http://arc.pasp.de/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

[grarpamp]

On Tue, Oct 13, 2015 at 4:08 PM, Razvan Dragomirescu
 wrote:
> essentially, I want to be able to host hidden service keys on the card. I'm
> trying to bind the hidden service to a hardware component (the smartcard) so
> that it can be securely hosted in a hostile environment as well as
> impossible to clone/move without physical access to the smartcard.

The host will have both physical and logical access to your
process space, therefore you're compromised regardless
of where you physically keep the keys or how you acccess
them.

Though there are trac tickets you can search for involving
loading keys into tor controller via remote tunnel without need
to leave and mount or access physical devices in /dev.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] adding smartcard support to Tor

[Razvan Dragomirescu]

Hello,

I am not sure if this has been discussed before or how hard it would be to
implement, but I'm looking for a way to integrate a smartcard with Tor -
essentially, I want to be able to host hidden service keys on the card. I'm
trying to bind the hidden service to a hardware component (the smartcard)
so that it can be securely hosted in a hostile environment as well as
impossible to clone/move without physical access to the smartcard.

I have Tor running on the USBArmory by InversePath (
http://inversepath.com/usbarmory.html ) and have a microSD form factor card
made by Swissbit (
www.swissbit.com/products/security-products/overwiev/security-products-overview/
) up and running on it. I am a JavaCard developer myself  and I have
developed embedded Linux firmwares before but I have never touched the Tor
source.

Is there anyone that is willing to take on a side project doing this? Would
it be just a matter of configuring OpenSSL to use the card (I haven't tried
that yet)?

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev