Re: Smartcards and tokens

[sivmu]

Am 18.12.2016 um 10:49 schrieb Peter Lebbing:
> On 18/12/16 01:56, Robert J. Hansen wrote:
>> Nope.  OpenPGP requires each RSA encryption add at least eight random
>> bytes to the data pre-encryption in order to make even identical
>> messages encrypt to different ciphertexts.
> 
> However, this randomness is added by the host, not by the smartcard. The
> OpenPGP smartcard really only does a deterministic action, and its
> correctness can be verified simply by doing the RSA public key operation
> on the output and checking that the result is identical to what was fed
> to the smartcard.
> 

Thats good to know. Thanks

> I can't think of a side channel to leak the private key to an attacker
> through an uncompromised host, but I wouldn't be surprised if there is
> such a side channel. Does anybody have a cool way to leak this? Single
> bits at a time will do! :-)
> 

Implement a GSM chip into the token? :)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Peter Lebbing]

On 18/12/16 01:56, Robert J. Hansen wrote:
> Nope.  OpenPGP requires each RSA encryption add at least eight random
> bytes to the data pre-encryption in order to make even identical
> messages encrypt to different ciphertexts.

However, this randomness is added by the host, not by the smartcard. The
OpenPGP smartcard really only does a deterministic action, and its
correctness can be verified simply by doing the RSA public key operation
on the output and checking that the result is identical to what was fed
to the smartcard.

I can't think of a side channel to leak the private key to an attacker
through an uncompromised host, but I wouldn't be surprised if there is
such a side channel. Does anybody have a cool way to leak this? Single
bits at a time will do! :-)

(We've already established that if the private key is generated on-card,
it is trivial to reconstruct it for an attacker that can insert a
backdoor into the smartcard)

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[sivmu]

Am 18.12.2016 um 01:30 schrieb Andrew Gallagher:
> 
>> On 18 Dec 2016, at 00:17, sivmu  wrote:
>>
>> ... that this means RSA encrzption is reproducable, meaning encrypted
>> files of the same plaintext result in the same ciphertext, as this woul
>> make the process reproduceable and any malfunction can be easily noticed.
> 
> No, because the plaintext is symmetric-encrypted with a random session key on 
> the host. The smartcard just asymmetric-encrypts the session key. This two 
> step process is used mainly because asymmetric encryption is comparatively 
> slow, but it also means that two identical plain texts won't get encrypted to 
> the same ciphertext, due to the random session key. 
> 
> A
> 

You are right, I forgot that.

Having some kind of way to check if the card is operating normally would
be awesome though...



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Robert J. Hansen]

>> The smartcard itself only RSA-decrypts the session key (or hash),
>> and this doesn't require an RNG.
> 
> ... that this means RSA encrzption is reproducable, meaning
> encrypted files of the same plaintext result in the same ciphertext,
> as this woul make the process reproduceable and any malfunction can
> be easily noticed.

Nope.  OpenPGP requires each RSA encryption add at least eight random
bytes to the data pre-encryption in order to make even identical
messages encrypt to different ciphertexts.  Search RFC4880 for a
reference to RFC3447 7.2.1, then look up RFC3447 7.2.1 and see how
EME-PKCS1-v1_5 encoding is defined.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Andrew Gallagher]

> On 18 Dec 2016, at 00:17, sivmu  wrote:
> 
> ... that this means RSA encrzption is reproducable, meaning encrypted
> files of the same plaintext result in the same ciphertext, as this woul
> make the process reproduceable and any malfunction can be easily noticed.

No, because the plaintext is symmetric-encrypted with a random session key on 
the host. The smartcard just asymmetric-encrypts the session key. This two step 
process is used mainly because asymmetric encryption is comparatively slow, but 
it also means that two identical plain texts won't get encrypted to the same 
ciphertext, due to the random session key. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[sivmu]

Am 16.12.2016 um 13:36 schrieb Andrew Gallagher:
> On 16/12/16 02:30, sivmu wrote:
>> If the token does the encryption (and signing) operations,
> 
> Smartcards perform signing and DEcryption (which in the case of RSA are
> mathematically identical).
> 
>> it needs randomness.
> 
> That's true of DSA and ElGamal, but smartcards normally implement RSA.
> 
> Remember also that PGP uses a two-step encryption process. The random
> symmetric session key is generated on the host rather than the
> smartcard, and the secure hash used in signing is deterministic.
> 

Thats what i wanted to hear. If the symmetric key is generated on the
host, that stops any scenario where the smartcard can subvertly
compromise the encryption process, assuming

> The smartcard itself only RSA-decrypts the session key (or hash), and
> this doesn't require an RNG.

... that this means RSA encrzption is reproducable, meaning encrypted
files of the same plaintext result in the same ciphertext, as this woul
make the process reproduceable and any malfunction can be easily noticed.

Signing could still be manipulated by a compromised smartcard I guess



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Andrew Gallagher]

On 16/12/16 18:33, Lou Wynn wrote:
> A brute force attack doesn't need to read the card, and
> it simply enumerates keys in the key space used by the SmartCard.

Yes, but the key space of the smartcard is much larger than the key
space of a USB drive encrypted using a key derived from a
human-readable passphrase...

A



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

On 12/15/2016 04:18 PM, Andrew Gallagher wrote:
>> On 15 Dec 2016, at 19:24, Lou Wynn  wrote:
>>
>> If the host machine is compromised, what's the purpose of doing encryption 
>> on the SmartCard? Attackers don't need to know the key to get your plaint 
>> ext, because it is on the host machine.
> The difference is that if you use a smart card in a compromised host, the 
> plaintext of particular messages may be compromised but the key itself 
> remains secure. It also helps in the case of hardware loss or theft, because 
> an encrypted drive can be brute forced, but smartcards have retry limits that 
> can't be worked around short of dissecting the silicon. 
I agree that a SmartCard can protect a private key, but that's a
marginal benefit because the bottom line of using a SmartCard is the
same as that of using an encrypted USB drive, which is

Do not use it in an untrusted or compromised host environment.

If you stick to the bottom line, then there is no point to emphasize the
difference.

The difference only comes in when you violate the bottom line and want
to use it in an untrusted or compromised host and "wish" that you could
get security. In this case, SmartCard can prevent your key from being
read. However, I would suggest anyone who uses a SmartCard not to do it
at all because using it in such an environment cannot give you security:
either signature or encryption.

I'd like to say more about "brute force" since you seem to misunderstand
the basic threat model of modern cryptography, whose design goal is only
to allow brute force attacks. However, it's computationally infeasible
in practice to guess the correct key by using brute force. A successful
cryptographic design is one where there is no systematic way to break it
unless an opponent can enumerate over the key space. SmartCard is no
immune to this. A brute force attack doesn't need to read the card, and
it simply enumerates keys in the key space used by the SmartCard. What
you said--limiting the number of reads on the card--is not a measure
against brute force. It is a measure to prevent reading secret materials.

-- 
Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Andrew Gallagher]

On 16/12/16 02:30, sivmu wrote:
> If the token does the encryption (and signing) operations,

Smartcards perform signing and DEcryption (which in the case of RSA are
mathematically identical).

> it needs randomness.

That's true of DSA and ElGamal, but smartcards normally implement RSA.

Remember also that PGP uses a two-step encryption process. The random
symmetric session key is generated on the host rather than the
smartcard, and the secure hash used in signing is deterministic.

The smartcard itself only RSA-decrypts the session key (or hash), and
this doesn't require an RNG.

Andrew.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Peter Lebbing]

On 15/12/16 22:17, Damien Goutte-Gattat wrote:
> I'll admit readily that I am not an expert on this, but I don't see how
> that could be feasible without the help of the host PC--meaning your
> opponent would have to both (1) compromise your PC and (2) send you a
> malicious token. But if he could compromise your PC, he would have no
> need for a malicious token.

However, the defining property of a smartcard is that in principle, the
private key cannot be extracted. That no longer holds for the party who
backdoored the smartcard, since they could add a special command that
extracts the private key.

> I guess your attacker could use a USB token as the mean to compromise
> your PC (names like "Bad USB" come to mind)

Also note that someone could "borrow" your card without you noticing,
rather than compromise your PC. This does depend on physically close
attackers being in your threat model. Your USB token could actually have
been compromised remotely on a different system, as a roundabout way of
compromising your machine in the end. So that one is actually possible
for remote attackers.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[sivmu]

Am 15.12.2016 um 22:17 schrieb Damien Goutte-Gattat:
> On 12/15/2016 08:35 PM, sivmu wrote:
>> From what I understand, a malicious token can e.g. perform encryption
>> operations with weak randomness to create some kind of backdoor that is
>> hard to detect.
> 
> The token is normally not used to perform any *encryption*. You encrypt
> with the public key of your correspondant, which is stored on your
> computer, not on your token (there's no need to protect it since it is a
> *public* key). You use your token to *decrypt* messages that were sent
> to you--and at that time, even if the token is malicious there's nothing
> it can do to mess with the encryption.
> 

I assumed the public key of the recipient is transferred to the token so
that it can do the encrytion internally. This is one of the things I
worry about. If the token does the encryption (and signing) operations,
it needs randomness. Something that is often messed with and hard to
produce reliably compared to a device with user interaction.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[NIIBE Yutaka]

sivmu  writes:
> it seems using those specific devices actually decreases
> security, assuming it is easy to manipulate specialised vendors of
> security hardware compared to manipulating electronic hardware in general.

Exactly, that's my point.  This is the reason why my approach of Gnuk
and NeuG tries to avoid specialized things.  Even, I avoid using crypto
accelerator, which (many of) experts say mandatory.

I think that an approach using commodity hardware makes sense.  My
theory is that if it's simpler and cheap enough, difficulty putting
backdoor would increase.  I don't know if this is true, but I considered
opposite must be likely; With enough space of silicon and enough
complexly in design, attackers can do something more.

> With nitrokey,  both the hardware design and the software is open source
> and both have been audited.

Is it audited?  I didn't know that.  For me, audit by an expert (or two)
is not enough.  It should be possible by anyone, or at least, by any
user who purchases it.  It's sad for me that Nitrokey is not easy to
open physically.  I mean, opening the device to examine the board.

> Bu I don't think that will keep some people from intercepting
> deliveries of such devices or mess with the production.

I don't know about the former, it depends on country.  For the latter,
it is real concern for me now.

I make the hardware design as simple as possible so that inspection by
human eye can be effective against replacing/adding chip.

Difficult part (for me) is to assure initial firmware flashing in
a factory.

In (most of) factory environment, proprietary operating system
dominates.  I'm not sure if this is the weakest link, but this could be
weaker point.  When an attacker replaces the firmware to be written,
it affects all devices to be shipped.

Perhaps, it would be good if an MCU has a feature of reporting hash of
its content of flash memory (even if flash is protected and it is not
possible to read out its content).  Then, an end user could examine
the hash code.

I think that the better current practice is: purchase commodity hardware
and flash at the user side.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Andrew Gallagher]

> On 15 Dec 2016, at 19:24, Lou Wynn  wrote:
> 
> If the host machine is compromised, what's the purpose of doing encryption on 
> the SmartCard? Attackers don't need to know the key to get your plaint ext, 
> because it is on the host machine.

The difference is that if you use a smart card in a compromised host, the 
plaintext of particular messages may be compromised but the key itself remains 
secure. It also helps in the case of hardware loss or theft, because an 
encrypted drive can be brute forced, but smartcards have retry limits that 
can't be worked around short of dissecting the silicon. 

That's assuming it has been sufficiently hardened against side channel attacks, 
of course. And if you leave the smart card in the machine with an insufficient 
pass phrase timeout, the attacker could feed an arbitrary number of messages 
through it without you knowing. So it's no panacea.

Andrew

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Damien Goutte-Gattat]

On 12/15/2016 08:35 PM, sivmu wrote:

From what I understand, a malicious token can e.g. perform encryption
operations with weak randomness to create some kind of backdoor that is
hard to detect.


The token is normally not used to perform any *encryption*. You encrypt 
with the public key of your correspondant, which is stored on your 
computer, not on your token (there's no need to protect it since it is a 
*public* key). You use your token to *decrypt* messages that were sent 
to you--and at that time, even if the token is malicious there's nothing 
it can do to mess with the encryption.


What a malicious (or faulty) token *could* do is generate a weak key, 
that your opponent could break once and for all and then use to decrypt 
all messages sent to you. Smartcards generating weak keys have already 
been observed in the wild [1]. If you worry about that, simply generate 
your keys on a computer you trust, then load them onto the token, 
without ever using the token's own random number generator.




Maybe there is also a way to secretly send the secret
keys loaded onto the smartcard/token to the adversary using the PC and
network it is used on.


I'll admit readily that I am not an expert on this, but I don't see how 
that could be feasible without the help of the host PC--meaning your 
opponent would have to both (1) compromise your PC and (2) send you a 
malicious token. But if he could compromise your PC, he would have no 
need for a malicious token.


I guess your attacker could use a USB token as the mean to compromise 
your PC (names like "Bad USB" come to mind), but if you worry about such 
attacks, you should be wary of *any* USB device you buy (keyboards, 
mice, mass storage sticks... or even desktop missile launchers), not 
only cryptographic devices.



Damien

[1] https://eprint.iacr.org/2013/599



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

Hi Martinho,

After I thought about it more, I have kind of drawn the conclusion that
even for signing, only using a SmartCard cannot achieve authenticity.

With a write-only SmartCard which computes signature on the card, it's
true that it can protect the signing key. However, if it's used in a
hacked machine or malicious environment, the hash sent to the card can
be modified to be the hash of something else, not the hash of the
document that you think you're reading on screen. Even if your signing
key is kept secret on the card, but it blindly signs a fake hash. What's
good about this?

So using a write-only SmartCard alonewithout a secure host environment
cannot give you the security level you think you get. Unless I missed
something from your original description.

This actually boils down a minimal trusted computing base (TCB).
SmartCard itself does not form a complete TCB, which must include
certain trusted host environment.



On 12/15/2016 11:24 AM, Lou Wynn wrote:
>
> If the host machine is compromised, what's the purpose of doing
> encryption on the SmartCard? Attackers don't need to know the key to
> get your plaint ext, because it is on the host machine.
>
> I guess that what you meant was signing, using a SmartCard to sign has
> the benefits you mentioned, but not encryption.
>
>
> On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
>> There's an important distinction to be made between using this
>> approach and using a SmartCard. The encrypted USB drive approach
>> leaks the keys into the machine you're using it from; they're
>> accessible by simply reading the filesystem (thus the claim that
>> "When you unplug the USB, your keys are gone." is wrong).  The keys
>> in a SmartCard are write-only; the SmartCard performs all the
>> encryption on-chip.
>>
>> You need to have an attack on the SmartCard to get the keys, while
>> with the USB drive approach, you just need to attack the host machine.
>>
>>
>> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>>
>>> I've come cross a simple and secure approach at this post:
>>>
>>> http://zacharyvoase.com/2009/08/20/openpgp/
>>>
>>> In the MAKING BACKUPS section, this method simply places your gnupg
>>> directory in an encrypted usb drive and make a symlink to it like this:
>>>
>>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>>
>>> That's all. As long as you use a good passphrase, this is very
>>> secure method to me. When you unplug the USB, your keys are gone. If
>>> your USB drive is lost, its content is encrypted by your passphrase,
>>> so no worry about it.
>>>
>>>
>>>
>>>
>>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
 sivmu   wrote:

> One question remaining is what is the difference between the openpgp
> smartcard and the USB based tokens.
>
 I think that the OpenPGP card (the physical smartcard) is included in
 Nitrokey Pro USB Token.  So, it's exactly same from the view point of
 smartcard.

 When you want to use a smartcard, you need a card reader to access the
 card.  And the card reader you use would bring another attack vectors.
 In this point, Nitrokey Pro USB Token is the best approach, I suppose.

 IIUC, Yubikey products are JavaCard implementations and somehow emulate
 OpenPGP card protocol by "app", and they work as CCID card reader +
 OpenPGP card.

 In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
 is implemented by Gnuk, the software.


> Also how much would you trust those vendors and can the use of such
> tokens actually decrease security?
>
 This is the point.

 The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
 man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
 Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
 Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
 should consider possibility of backdoor of OpenPGP card.  Well, I don't
 know about Yubikey.

 When it is replaced to be malicious one to enable an access by others
 (to your private keys), or it already has a backdoor in the first place,
 it kills the purpose of USB security token.

 Here, the question is: how can we build up such a "trust"?

 It seems for me that there are two different approaches; (1) physical
 difficulty (for example, plastic molding for "protection"), (2)
 reproducibility and transparency/openness.  Note that some method of
 former makes latter difficult.


 For myself, I take (2), and I did my best to make my product as
 reproducible.  (Since I don't manufacture semiconductor things,
 reproducibility is not 100%, and this part of manufacturing and
 technology is not open at all.)  And I intentionally deliver my product
 in a style of "transparent" or "open".

 Distribution channel is also 

Re: Smartcards and tokens

[sivmu]

Am 15.12.2016 um 02:35 schrieb NIIBE Yutaka:
> sivmu  wrote:
>> One question remaining is what is the difference between the openpgp
>> smartcard and the USB based tokens.
> 
> I think that the OpenPGP card (the physical smartcard) is included in
> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
> smartcard.
> 
> When you want to use a smartcard, you need a card reader to access the
> card.  And the card reader you use would bring another attack vectors.
> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
> 
> IIUC, Yubikey products are JavaCard implementations and somehow emulate
> OpenPGP card protocol by "app", and they work as CCID card reader +
> OpenPGP card.
> 
> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
> is implemented by Gnuk, the software.
> 
>> Also how much would you trust those vendors and can the use of such
>> tokens actually decrease security?
> 
> This is the point.
> 
> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
> should consider possibility of backdoor of OpenPGP card.  Well, I don't
> know about Yubikey.
> 
> When it is replaced to be malicious one to enable an access by others
> (to your private keys), or it already has a backdoor in the first place,
> it kills the purpose of USB security token.
> 
> Here, the question is: how can we build up such a "trust"?
> 
> It seems for me that there are two different approaches; (1) physical
> difficulty (for example, plastic molding for "protection"), (2)
> reproducibility and transparency/openness.  Note that some method of
> former makes latter difficult.
> 
> 
> For myself, I take (2), and I did my best to make my product as
> reproducible.  (Since I don't manufacture semiconductor things,
> reproducibility is not 100%, and this part of manufacturing and
> technology is not open at all.)  And I intentionally deliver my product
> in a style of "transparent" or "open".
> 
> Distribution channel is also difficult.  I do in person, and I ask FSF
> for my TRNG.  Are there any good method?
> 
> Obvious drawback of the apporoach (2) is that people with enough
> concern/attention have tendency to do it under their control.
> Reasonable.  Since it's reproducible (somehow), it's possible, by
> definition.  And then, I can't sell many.
> 

From what I understand, a malicious token can e.g. perform encryption
operations with weak randomness to create some kind of backdoor that is
hard to detect. Maybe there is also a way to secretly send the secret
keys loaded onto the smartcard/token to the adversary using the PC and
network it is used on.

If there is no way to detect such malicious devices and given that
certain organisations tend to mess with security tokens and crypto
devices, it seems using those specific devices actually decreases
security, assuming it is easy to manipulate specialised vendors of
security hardware compared to manipulating electronic hardware in general.

Or is this too much of a conspiracy theorie? (not that those do not have
a tendency to be outrun by reality anyway)

With nitrokey,  both the hardware design and the software is open source
and both have been audited. Bu I don't think that will keep some people
from intercepting deliveries of such devices or mess with the production.

I'm really not sure if specialised devices for crypto is a good idea,
give that it presents such a promising target.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

If the host machine is compromised, what's the purpose of doing
encryption on the SmartCard? Attackers don't need to know the key to get
your plaint ext, because it is on the host machine.

I guess that what you meant was signing, using a SmartCard to sign has
the benefits you mentioned, but not encryption.


On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
> There's an important distinction to be made between using this
> approach and using a SmartCard. The encrypted USB drive approach leaks
> the keys into the machine you're using it from; they're accessible by
> simply reading the filesystem (thus the claim that "When you unplug
> the USB, your keys are gone." is wrong).  The keys in a SmartCard are
> write-only; the SmartCard performs all the encryption on-chip.
>
> You need to have an attack on the SmartCard to get the keys, while
> with the USB drive approach, you just need to attack the host machine.
>
>
> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>
>> I've come cross a simple and secure approach at this post:
>>
>> http://zacharyvoase.com/2009/08/20/openpgp/
>>
>> In the MAKING BACKUPS section, this method simply places your gnupg
>> directory in an encrypted usb drive and make a symlink to it like this:
>>
>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>
>> That's all. As long as you use a good passphrase, this is very secure
>> method to me. When you unplug the USB, your keys are gone. If your
>> USB drive is lost, its content is encrypted by your passphrase, so no
>> worry about it.
>>
>>
>>
>>
>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>>> sivmu   wrote:
>>>
 One question remaining is what is the difference between the openpgp
 smartcard and the USB based tokens.

>>> I think that the OpenPGP card (the physical smartcard) is included in
>>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>>> smartcard.
>>>
>>> When you want to use a smartcard, you need a card reader to access the
>>> card.  And the card reader you use would bring another attack vectors.
>>> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>>>
>>> IIUC, Yubikey products are JavaCard implementations and somehow emulate
>>> OpenPGP card protocol by "app", and they work as CCID card reader +
>>> OpenPGP card.
>>>
>>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
>>> is implemented by Gnuk, the software.
>>>
>>>
 Also how much would you trust those vendors and can the use of such
 tokens actually decrease security?

>>> This is the point.
>>>
>>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
>>> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
>>> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
>>> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
>>> should consider possibility of backdoor of OpenPGP card.  Well, I don't
>>> know about Yubikey.
>>>
>>> When it is replaced to be malicious one to enable an access by others
>>> (to your private keys), or it already has a backdoor in the first place,
>>> it kills the purpose of USB security token.
>>>
>>> Here, the question is: how can we build up such a "trust"?
>>>
>>> It seems for me that there are two different approaches; (1) physical
>>> difficulty (for example, plastic molding for "protection"), (2)
>>> reproducibility and transparency/openness.  Note that some method of
>>> former makes latter difficult.
>>>
>>>
>>> For myself, I take (2), and I did my best to make my product as
>>> reproducible.  (Since I don't manufacture semiconductor things,
>>> reproducibility is not 100%, and this part of manufacturing and
>>> technology is not open at all.)  And I intentionally deliver my product
>>> in a style of "transparent" or "open".
>>>
>>> Distribution channel is also difficult.  I do in person, and I ask FSF
>>> for my TRNG.  Are there any good method?
>>>
>>> Obvious drawback of the apporoach (2) is that people with enough
>>> concern/attention have tendency to do it under their control.
>>> Reasonable.  Since it's reproducible (somehow), it's possible, by
>>> definition.  And then, I can't sell many.
>>>
>>
>> _
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org 
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[R. Martinho Fernandes]

There's an important distinction to be made between using this approach
and using a SmartCard. The encrypted USB drive approach leaks the keys
into the machine you're using it from; they're accessible by simply
reading the filesystem (thus the claim that "When you unplug the USB,
your keys are gone." is wrong).  The keys in a SmartCard are write-only;
the SmartCard performs all the encryption on-chip.


You need to have an attack on the SmartCard to get the keys, while with
the USB drive approach, you just need to attack the host machine.




On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:

> I've come cross a simple and secure approach at this post:



> http://zacharyvoase.com/2009/08/20/openpgp/



> In the MAKING BACKUPS section, this method simply places your
> gnupg directory in an encrypted usb drive and make a symlink to it
> like this:


> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>
> That's all. As long as you use a good passphrase, this is very secure
> method to me. When you unplug the USB, your keys are gone. If your USB
> drive is lost, its content is encrypted by your passphrase, so no
> worry about it.
> 

> 

> 

> 

> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>> sivmu  wrote:
>>
>>> One question remaining is what is the difference between the openpgp
>>> smartcard and the USB based tokens.
>>>
>> I think that the OpenPGP card (the physical smartcard) is included in
>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>> smartcard.  When you want to use a smartcard, you need a card reader
>> to access the card.  And the card reader you use would bring another
>> attack vectors. In this point, Nitrokey Pro USB Token is the best
>> approach, I suppose.  IIUC, Yubikey products are JavaCard
>> implementations and somehow emulate OpenPGP card protocol by "app",
>> and they work as CCID card reader + OpenPGP card.  In Nitrokey Start
>> USB Token, there is no OpenPGP card physically, but it is implemented
>> by Gnuk, the software.

>>
>>> Also how much would you trust those vendors and can the use of such
>>> tokens actually decrease security?
>>>
>> This is the point.  The hardware OpenPGP card in Nitrokey Pro USB
>> Token could be replaced by man in the middle (or its vendor).  The
>> hardware MCU chip in Nitrokey Start USB Token could be replaced, too.
>> The software (Gnuk) in Nitrokey Start USB Token could be replaced
>> (with JTAG/SWD debugger), too.  Or, we should consider possibility of
>> backdoor of OpenPGP card.  Well, I don't know about Yubikey.  When it
>> is replaced to be malicious one to enable an access by others (to
>> your private keys), or it already has a backdoor in the first place,
>> it kills the purpose of USB security token.  Here, the question is:
>> how can we build up such a "trust"?  It seems for me that there are
>> two different approaches; (1) physical difficulty (for example,
>> plastic molding for "protection"), (2) reproducibility and
>> transparency/openness.  Note that some method of former makes latter
>> difficult.   For myself, I take (2), and I did my best to make my
>> product as reproducible.  (Since I don't manufacture semiconductor
>> things, reproducibility is not 100%, and this part of manufacturing
>> and technology is not open at all.)  And I intentionally deliver my
>> product in a style of "transparent" or "open".  Distribution channel
>> is also difficult.  I do in person, and I ask FSF for my TRNG.  Are
>> there any good method?  Obvious drawback of the apporoach (2) is that
>> people with enough concern/attention have tendency to do it under
>> their control. Reasonable.  Since it's reproducible (somehow), it's
>> possible, by definition.  And then, I can't sell many.
>>
> 

> _

> Gnupg-users mailing list

> Gnupg-users@gnupg.org

> http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

I've come cross a simple and secure approach at this post:

http://zacharyvoase.com/2009/08/20/openpgp/

In the MAKING BACKUPS section, this method simply places your gnupg
directory in an encrypted usb drive and make a symlink to it like this:

ln -s /Volumes/EncDrive/gnupg ~/.gnupg

That's all. As long as you use a good passphrase, this is very secure
method to me. When you unplug the USB, your keys are gone. If your USB
drive is lost, its content is encrypted by your passphrase, so no worry
about it.



On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
> sivmu  wrote:
>> One question remaining is what is the difference between the openpgp
>> smartcard and the USB based tokens.
> I think that the OpenPGP card (the physical smartcard) is included in
> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
> smartcard.
>
> When you want to use a smartcard, you need a card reader to access the
> card.  And the card reader you use would bring another attack vectors.
> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>
> IIUC, Yubikey products are JavaCard implementations and somehow emulate
> OpenPGP card protocol by "app", and they work as CCID card reader +
> OpenPGP card.
>
> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
> is implemented by Gnuk, the software.
>
>> Also how much would you trust those vendors and can the use of such
>> tokens actually decrease security?
> This is the point.
>
> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
> should consider possibility of backdoor of OpenPGP card.  Well, I don't
> know about Yubikey.
>
> When it is replaced to be malicious one to enable an access by others
> (to your private keys), or it already has a backdoor in the first place,
> it kills the purpose of USB security token.
>
> Here, the question is: how can we build up such a "trust"?
>
> It seems for me that there are two different approaches; (1) physical
> difficulty (for example, plastic molding for "protection"), (2)
> reproducibility and transparency/openness.  Note that some method of
> former makes latter difficult.
>
>
> For myself, I take (2), and I did my best to make my product as
> reproducible.  (Since I don't manufacture semiconductor things,
> reproducibility is not 100%, and this part of manufacturing and
> technology is not open at all.)  And I intentionally deliver my product
> in a style of "transparent" or "open".
>
> Distribution channel is also difficult.  I do in person, and I ask FSF
> for my TRNG.  Are there any good method?
>
> Obvious drawback of the apporoach (2) is that people with enough
> concern/attention have tendency to do it under their control.
> Reasonable.  Since it's reproducible (somehow), it's possible, by
> definition.  And then, I can't sell many.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[NIIBE Yutaka]

sivmu  wrote:
> One question remaining is what is the difference between the openpgp
> smartcard and the USB based tokens.

I think that the OpenPGP card (the physical smartcard) is included in
Nitrokey Pro USB Token.  So, it's exactly same from the view point of
smartcard.

When you want to use a smartcard, you need a card reader to access the
card.  And the card reader you use would bring another attack vectors.
In this point, Nitrokey Pro USB Token is the best approach, I suppose.

IIUC, Yubikey products are JavaCard implementations and somehow emulate
OpenPGP card protocol by "app", and they work as CCID card reader +
OpenPGP card.

In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
is implemented by Gnuk, the software.

> Also how much would you trust those vendors and can the use of such
> tokens actually decrease security?

This is the point.

The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
should consider possibility of backdoor of OpenPGP card.  Well, I don't
know about Yubikey.

When it is replaced to be malicious one to enable an access by others
(to your private keys), or it already has a backdoor in the first place,
it kills the purpose of USB security token.

Here, the question is: how can we build up such a "trust"?

It seems for me that there are two different approaches; (1) physical
difficulty (for example, plastic molding for "protection"), (2)
reproducibility and transparency/openness.  Note that some method of
former makes latter difficult.


For myself, I take (2), and I did my best to make my product as
reproducible.  (Since I don't manufacture semiconductor things,
reproducibility is not 100%, and this part of manufacturing and
technology is not open at all.)  And I intentionally deliver my product
in a style of "transparent" or "open".

Distribution channel is also difficult.  I do in person, and I ask FSF
for my TRNG.  Are there any good method?

Obvious drawback of the apporoach (2) is that people with enough
concern/attention have tendency to do it under their control.
Reasonable.  Since it's reproducible (somehow), it's possible, by
definition.  And then, I can't sell many.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users