Re: Manually changing smartcard state

[Jernej Kos]

Hello!

On 27. 01. 2015 01:00, Johannes Zarl wrote:
> You can tell gpg-agent to lock the card using the following command[1]:
> 
> gpg-connect-agent 'SCD RESET' /bye

Nice, this works, thank you!


Jernej



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

Re: Talking about Cryptodevices... which one?

[Andreas Schwier]

On 01/27/2015 05:24 PM, Felix E. Klee wrote:
> A smart card stores the key unencrypted, right?
Quite typically not. The platform we use for the SmartCard-HSM generates
a random AES key during platform initialization and encrypts all key
material in EEPROM under this key. The only time the key is handled in
plain (plain meaning within the protected enclosure of the secure
microcontroller) is when the crypto unit performs a private key operation.

While the device is at rest, key material in EEPROM is encrypted, the
AES key is stored in a CPU memory area separate from the main EEPROM.

The same should be try for OpenPGP cards based on a JavaCard applet.
Can't tell how it is done on other OpenGPG compliant cards.

Of course a more important aspect is resistance to various side channel
attacks (DFA/DPA and a like). Mitigating that risk is quite challenging.

Andreas

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


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


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

Re: Talking about Cryptodevices... which one?

[Andreas Schwier]

On 01/24/2015 08:27 PM, Hauke Laging wrote:
> The OpenPGP card does provide the opportunity to backup the on the card 
> generated key material.
Yes, but that uses a plain import/export of private keys, which defeats
the purpose of using a smart card to protect confidentiality of the keys.

I'd rather want a proper key escrow scheme were private keys are never
exposed at any interface.
> 
> 
> Hauke
> 
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


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

Re: Talking about Cryptodevices... which one?

[Felix E. Klee]

On Sat, Jan 24, 2015 at 4:05 AM, NIIBE Yutaka  wrote:
> gnuk (running on the FST-01)

How does that store the private key? Password encrypted?

A smart card stores the key unencrypted, right?

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

Re: Talking about Cryptodevices... which one?

[Felix E. Klee]

On Tue, Jan 27, 2015 at 5:19 PM, Andreas Schwier
 wrote:
> The platform we use for the SmartCard-HSM generates a random AES key
> during platform initialization and encrypts all key material in EEPROM
> under this key. The only time the key is handled in plain (plain
> meaning within the protected enclosure of the secure microcontroller)
> is when the crypto unit performs a private key operation.

Good! What PIN length do you recommend? (for the case that there is a
backdoor to get the *encrypted* key off the card)

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

Re: Talking about Cryptodevices... which one?

[Andreas Schwier]

> Good! What PIN length do you recommend? (for the case that there is a
> backdoor to get the *encrypted* key off the card)
The encryption on the card is unrelated to the PIN. It's rather an
authentication object that blocks private key operations until the user
has entered the correct PIN.

With a retry counter of 3, I'd recommend a 6 digit PIN.

Andreas


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


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

Re: Talking about Cryptodevices... which one?

[Felix E. Klee]

On Tue, Jan 27, 2015 at 6:14 PM, Andreas Schwier
 wrote:
> The encryption on the card is unrelated to the PIN.

So the private key is encrypted with an AES key that is also stored on
the card? Then why encrypt the private key at all? Against what attack
does encryption of the private key on the card protect?

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

Re: Talking about Cryptodevices... which one?

[Andreas Schwier]

On 01/27/2015 07:35 PM, Felix E. Klee wrote:
> On Tue, Jan 27, 2015 at 6:14 PM, Andreas Schwier
>  wrote:
>> The encryption on the card is unrelated to the PIN.
> 
> So the private key is encrypted with an AES key that is also stored on
> the card? Then why encrypt the private key at all? Against what attack
> does encryption of the private key on the card protect?
Against certain hardware attacks that try to extract information from
EEPROM cells on the chip. The AES key is not stored in main EEPROM area
of the chip.

Encrypting keys at rest is just an additional measure beside all kind of
other tamper protection mechanisms implemented in modern smart card
micro controller.
> 


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


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

Publickey Algorithm IDs for --command-fd

[David Url]

Hello,

I was trying to automate the generation of subkeys, using the --command-fd 
option like this:
gpg --homedir /tmp/gnupgtest --status-fd 2 --no-tty --command-fd 0 
--with-colons --edit-key E458A481 addkey

But i could not find the public key algorithm ids for ‘GET_LINE keygen.algo’ 
anywhere in the documentation.
It looks like the integers from the commandline interface without --command-fd, 
but is there any documentation on that?

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

Re: Publickey Algorithm IDs for --command-fd

[Werner Koch]

On Tue, 27 Jan 2015 21:29, da...@x00.at said:

> But i could not find the public key algorithm ids for ‘GET_LINE
> keygen.algo’ anywhere in the documentation.  It looks like the
> integers from the commandline interface without --command-fd, but is
> there any documentation on that?

No.  And worse this is not a stable interface.  I have an idea on how to
solve this for 2.1 and it can also be backported to 1.4 and 2.0.  Please
give me some time until tomorrow.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Talking about Cryptodevices... which one?

[Peter Lebbing]

On 27/01/15 21:01, Andreas Schwier wrote:
> Against certain hardware attacks that try to extract information from
> EEPROM cells on the chip. The AES key is not stored in main EEPROM area
> of the chip.

To put it in slightly different terms:

The AES key is only 16 or 32 bytes long (16 most likely). An RSA private key is
much longer. The 16 bytes holding the AES key are super well protected against
extraction, but this is expensive to produce on chip. The AES-encrypted private
key is stored in less protected memory, but the data is useless without
extracting the very well protected AES key.

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: Talking about Cryptodevices... which one?

[NIIBE Yutaka]

Thank you for your question.

On 01/28/2015 01:24 AM, Felix E. Klee wrote:
> On Sat, Jan 24, 2015 at 4:05 AM, NIIBE Yutaka  wrote:
>> gnuk (running on the FST-01)
> 
> How does that store the private key? Password encrypted?

Gnuk stores private keys encrypted by AES.  The data encryption key
(DEK) of AES is generated by a TRNG routine named NeuG.  This DEK is
then encrypted by another AES KEY generated by S2K (string to key)
function with passphrase.  Gnuk's S2K function is taken from OpenPGP
specification (and with SHA256).  It's default s2kcount is 192 as the
MCU is slow enough, but you can configure it at compile time (like
65535 for host PC, or more).

>From the viewpoint of getting unencrypted private key, it's like:

 On flash ROM: Private key encrypted --\
\
 On flash ROM: DEK encrypted --\   [AES]--> Private key
  [AES]-> DEK --/
   Passphrase --[S2K]--/

It's much like OpenPGP, but Gnuk has additional step, because
OpenPGPcard specification also allows admin to access user's private
key.  This would be a weak point of OpenPGPcard specification, so,
Gnuk has its original feature to disable "admin" role.

*   *   *

When we evaluate possible attacks, I think that it is very important
for us, OpenPGP users, who value the users control of their computing,
to understand the difference between:

the structure of traditional smartcard industry

the specific usage of OpenPGP with smartcard/token

For smartcard industry, "user" is actually the entity who purchases
the smartcard, and most of the cases, it's *not* the end user, but
it's a company who forces using smartcard to its customer/employee.
In this structure, "user" cares about the attacks by its
customer/employee.

On the other hand, typical usage of OpenPGPcard is by the end user of
GnuPG.  I realized that people tend to talk with the assumption of
smartcard industry, without considering our specific usage.


For Gnuk, serious threat would be software vulnerabilities of itself.

There would be a possible hole to circumvent "three time failures" of
passphrase.  Even if we had such a hole, slow enough S2K function
tries to prevent access to raw private key.  There would be a possible
hole to access MCU's internal flash directly.  In this case,
dictionary attack would be most effective (Gnuk allows passphrase
length up to 127, though).  Given the NeuG's randomness is good
enough, breaking encrypted private key directly would be difficult.

There would be a possible hole to get access to raw private key when
it's loaded to MCU's internal RAM, or by its computation side channel.
Well, I do my best not to have such a hole.  It's not for Gnuk, but I
fixed some in libgcrypt/GnuPG, you can evaluate those, say, changes in
the RSA implementation.

*   *   *

The important point of using smartcard/token is to put your private
key under better control (as well as other points like portability,
etc.).  I think that it's better to use smartcard/token, than storing
the private key on disk of host PC.  Because it could be more simple
and solid.

>From this point, it is better for smartcard/token, not to have other
"useful features".  I'm afraid that something like that simply means
inviting more vulnerabilities or risks.

People might like "powerful" processor.  But, "slow enough" is an
important factor in my own threat model.  It's interesting that card
readers tend to have more powerful MCU than FST-01, these days.
-- 

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