opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Alexander G. <ago...@gm...>]

Hi Peter,

Here is the OpenSSL Engine that we wrote by the Atmel request:
https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports
ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine
also supports keeping certificates on the ATECC508A hardware. Like Douglas
and David already said, it will not add any protection. But it is
implemented. Youy can use it.

We do not use OpenCS in this project: we found that we didn't need any http
support. Let me know if you want to talk to Atmel's FAE: they are very
responsive and knowledgeable.

Regards,
Alex

On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <Pet...@kn...>
wrote:

> good point. Hopefully we can limit the enrollment to a trusted
> subcontractor's network. As the UUIDs resemble a known set which is relayed
> from ATMEL to us before the chips are soldered onto the boards,
> only "spoofing" UUIDs out of this set would be the final attack vector I
> can't mitigate.
>
> -----Original Message-----
> From: Douglas E Engert [mailto:dee...@gm...]
> Sent: Wednesday, June 15, 2016 4:20 PM
> To: ope...@li...
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
>
>
> On 6/15/2016 8:57 AM, Marx, Peter wrote:
> > let's start with the requirements part:
> >
> > 1. I want hardware security. Key pair generation shall happen on device
> and private key shall not leave the device. Minimum solution would be to do
> this with WolfSSL or OpenSSL plus the existing ATECC108 support.
> >
> > 2a. I want to leverage the UUID existing in the chip to safeguard the
> TLS certificate enrollment process towards the PKI, where the UUIDs are
> pre-registered. Idea is to prevent  illegal hardware copies.
> >
> > 2b. TLS client certificate CSR shall be created based on the UUID and
> the keypair. Resulting client cert signed by the CA (via SCEP) today goes
> into Java Keystore file. CA cert or TLS server cert go into java truststore
> file.
> > The keystore and truststore files plus the cleartext passwords to
> > access them are configured in ActiveMQ. As this is potentially unsecure,
> I had the idea of leveraging the chip a second time by storing the certs in
> it and providing a PKCS#11 interface to them, so that Java applications
> like AMQ can access them in a transparant way. Only Java JCE
> reconfiguration plus a little AMQ tweak would be necessary.
> >
> > Based on these requirements I'm not sure whether storing the certs in
> SoftHSM would be beneficial - one could still take away the certs and use
> them on another hardware.
>
> But the public key in the cert only works with the private key in the
> device. Copying the certs should not work.
> This security depends on the CA only signing a CSR with the UUID from the
> chip. That is not clear how the CA verifies the UUID is the one on the
> chip. This is a card management issue for the CA.  If the CA is only
> signing CSRs generated at you factory where you have physical control of
> the chip, then it could work. If the CSR is generated by the user or in the
> field, the CA may not be able to validate the UUID is from the chip that
> signed the CSR.
>
> >
> > I had checked TPM also, but more for safeguarding the boot process and
> integrity of the OS. And as a TPM chip is too bulky (28 pins) for our
> board, it wasn't an option anyway.
> > For TLS via Java there is also no option to interfere with the
> encryption (at least to my maybe incomplete knowledge), so again no
> solution path.
> >
> > For something like data encryption before transmitting you have more
> options, as you code yourself. There your proposal of "TPM light" could
> indeed be an option.
> >
> > Peter
> >
> >
> > -----Original Message-----
> > From: David Woodhouse [mailto:dw...@in...]
> > Sent: Tuesday, June 14, 2016 1:12 PM
> > To: Marx, Peter; ope...@li...
> > Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
> >
> > * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
> >
> > On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
> >> I’m IT architect in a big IoT project. I’m looking for getting
> >> PKCS#11 support for Java applications on Linux, so i can get rid of
> >> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
> >> shall be created/stored in hardware instead.
> >>
> >> But I can’t use Smartcards. The idea is to use a cryptochip on the
> >> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
> >> chip is on I2C bus and is e.g. accessible from Linux as a device.
> > OK... first question: why do you want certificates in hardware? What's
> the point in that?
> >
> > Is there some kind of design requirement where you want to be able to
> wipe and re-image the operating system storage, but leave the
> > *certificates* in the store intact? And even if it's that, isn't it
> easier to just have separate storage for the certificates?
> >
> > Here's a straw man proposal; tell me why/if it doesn't work for you.
> >
> > Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn
> (which is entirely usable outside NSS; I was using it with wpa_supplicant
> only a few hours ago). That's your certificate storage.
> >
> > For keys though, this doesn't work — I assume you're here because you
> really *do* want hardware security so that the private key can't be copied
> away from the device; only used in situ.
> >
> > For this, the TPM model works. Not the whole complex TSS stack, but just
> the basic concept — you store your private keys in software, but
> *encrypted*. With a key that only exists inside the hardware (and is fairly
> much the *only* thing the hardware stores).
> >
> > So when you want to perform an encrypt/decrypt/sign/verify operation
> with a given key, you hand the encrypted key to the Atmel µc and ask
> > *it* to decrypt the key and then perform the operation. Optionally, it
> can demand a PIN when you do so.
> >
> > I'm not sure how well that would fit into OpenSC, but it does seem like
> the low-effort way to achieving (what I assume to be) your requirements.
> >
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
> Knorr-Bremse IT-Services GmbH
> Sitz: Muenchen
> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald
> Schneider
> Registergericht Muenchen, HR B 167 268
>
> This transmission is intended solely for the addressee and contains
> confidential information.
> If you are not the intended recipient, please immediately inform the
> sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to
> anyone unless agreed otherwise. To the extent permitted by law we shall in
> no way be liable for any damages, whatever their nature, arising out of
> transmission failures, viruses, external influence, delays and the like.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Marx, P. <Pet...@kn...>]

good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards,
only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate.

-----Original Message-----
From: Douglas E Engert [mailto:dee...@gm...] 
Sent: Wednesday, June 15, 2016 4:20 PM
To: ope...@li...
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?



On 6/15/2016 8:57 AM, Marx, Peter wrote:
> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to 
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:dw...@in...]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; ope...@li...
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>   
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

-- 

  Douglas E. Engert  <DEE...@gm...>
  


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Marx, P. <Pet...@kn...>]

but I don't have a PKCS#11 module for the ATECC108. This seems to be the missing link, as such modules are only existing for HSMs and Smartcards. They are delivered by their producers. 
My question is how to create such a module, hopefully by adopting an existing solution. 

-----Original Message-----
From: Andreas Schwier [mailto:and...@ca...] 
Sent: Wednesday, June 15, 2016 4:14 PM
To: ope...@li...
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

TLS via Java with a PKCS#11 Module can be done with opensc-java or the
SunPKCS11 Provider. That works for both, client and server authentication.

On 06/15/2016 03:57 PM, Marx, Peter wrote:
> let's start with the requirements part: 
> 
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
> 
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies. 
> 
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to 
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
> 
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.
> 
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
> 
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
> 
> Peter
> 
> 
> -----Original Message-----
> From: David Woodhouse [mailto:dw...@in...]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; ope...@li...
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
> 
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
> 
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of 
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys 
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the 
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The 
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> 
> OK... first question: why do you want certificates in hardware? What's the point in that?
> 
> Is there some kind of design requirement where you want to be able to 
> wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
> 
> Here's a straw man proposal; tell me why/if it doesn't work for you.
> 
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
> 
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
> 
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
> 
> So when you want to perform an encrypt/decrypt/sign/verify operation 
> with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
> 
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
> 


-- 

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Douglas E E. <dee...@gm...>]

On 6/15/2016 8:57 AM, Marx, Peter wrote:
> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
> providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If 
the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to 
validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:dw...@in...]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; ope...@li...
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>   
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

-- 

  Douglas E. Engert  <DEE...@gm...>
  

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Andreas S. <and...@ca...>]

TLS via Java with a PKCS#11 Module can be done with opensc-java or the
SunPKCS11 Provider. That works for both, client and server authentication.

On 06/15/2016 03:57 PM, Marx, Peter wrote:
> let's start with the requirements part: 
> 
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
> 
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies. 
> 
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
> providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
> 
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.
> 
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
> 
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
> 
> Peter
> 
> 
> -----Original Message-----
> From: David Woodhouse [mailto:dw...@in...] 
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; ope...@li...
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
> 
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
> 
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of 
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys 
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the 
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The 
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> 
> OK... first question: why do you want certificates in hardware? What's the point in that?
> 
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
> 
> Here's a straw man proposal; tell me why/if it doesn't work for you.
> 
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
> 
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
> 
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
> 
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
> 
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
> 


-- 

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Marx, P. <Pet...@kn...>]

let's start with the requirements part: 

1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.

2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies. 

2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.

Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.

For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.

Peter


-----Original Message-----
From: David Woodhouse [mailto:dw...@in...] 
Sent: Tuesday, June 14, 2016 1:12 PM
To: Marx, Peter; ope...@li...
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

* PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM

On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
> I’m IT architect in a big IoT project. I’m looking for getting
> PKCS#11 support for Java applications on Linux, so i can get rid of 
> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys 
> shall be created/stored in hardware instead.
>  
> But I can’t use Smartcards. The idea is to use a cryptochip on the 
> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The 
> chip is on I2C bus and is e.g. accessible from Linux as a device.

OK... first question: why do you want certificates in hardware? What's the point in that?

Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
*certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?

Here's a straw man proposal; tell me why/if it doesn't work for you.

Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.

For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.

For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).

So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
*it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.

I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

* dw...@in... <dw...@in...>
* Issuer: StartCom Ltd. - Unverified

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Anders R. <and...@gm...>]

On 2016-06-14 13:11, David Woodhouse wrote:
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> OK... first question: why do you want certificates in hardware?
> What's the point in that?
>
> Is there some kind of design requirement where you want to be able to
> wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it
> easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS
> softokn (which is entirely usable outside NSS; I was using it with
> wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you
> really *do* want hardware security so that the private key can't be
> copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but
> just the basic concept — you store your private keys in software, but
> *encrypted*. With a key that only exists inside the hardware (and is
> fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation
> with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it
> can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like
> the low-effort way to achieving (what I assume to be) your
> requirements.

Since Intel have firmware in their CPUs it seems that Intel is the
party that should enable this capability...

Unfortunately Intel seems to be fairly uninterested in solutions
they don't get paid for in spite of the fact that their IPT system
http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/identity-protection-technology-general.html
probably haven't generated a single cent in profits ever.

Anders

>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Marx, P. <Pet...@kn...>]

Hi Andreas,

there is no more chance to introduce something like the NXP A700 to the board design, so I'm stuck with the ATMEL...
A smaller stack could be an option, but a read-only implementation could be insufficient, as provisioning process and in-field usage would take different paths, tools and methods. But this has to be clarified.

Reading though your sc-hsm-embedded link, I don't get an idea what kind of drivers/modules need to be implemented to get that stuff work with the ATMEL chip, may it be through a Linux device or directly.
Could you give some hints here ?

Peter


-----Original Message-----
From: Andreas Schwier [mailto:and...@ca...] 
Sent: Tuesday, June 14, 2016 12:15 PM
To: ope...@li...
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

Hi Peter,

I'd recommend to use a Secure Element platform like the NXP A700 which has a JavaCard Operating System and can run JavaCard applets implementing PKI functions.

That way you get an embedded smartcard controller that has the security attributes you are looking for. You could use one of the available JavaCard applets that work with OpenSC, e.g.

* the IsoApplet [2],
* the myEID Applet [3] or
* (of course) our SmartCard-HSM Applet [4].

If you want to go with the Atmel chip, integrating a stack smaller than OpenSC might be simpler. I'd recommend to take a look at our sc-hsm-embedded project, which is a lightweight PKCS#11 stack for embedded scenarios.

Andreas



[1]
http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
[2] https://github.com/philipWendland/IsoApplet
[3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
[4] http://www.smartcard-hsm.com/
[5] https://github.com/CardContact/sc-hsm-embedded

On 06/14/2016 11:42 AM, Marx, Peter wrote:
> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
> 
> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
> 
> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
> 
> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
> 
> 
> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
> 
> -          Has this been done before ?
> 
> -          Can this be purchased or is it available for free ?
> 
> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
> 
> -          What effort would this be ?
> 
> -          In case there is no open solution: who knows a company which could deliver a solution ?
> 
> Peter
> 
> Knorr-Bremse IT-Services GmbH
> Sitz: Muenchen
> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, 
> Harald Schneider Registergericht Muenchen, HR B 167 268
> 
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
> 
> 
> 
> ----------------------------------------------------------------------
> -------- What NetFlow Analyzer can do for you? Monitors network 
> bandwidth and traffic patterns at an interface-level. Reveals which 
> users, apps, and protocols are consuming the most bandwidth. Provides 
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 
> informed decisions using capacity planning reports. 
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 


-- 

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[David W. <dw...@in...>]

On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
> I’m IT architect in a big IoT project. I’m looking for getting
> PKCS#11 support for Java applications on Linux, so i can get rid of
> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
> shall be created/stored in hardware instead.
>  
> But I can’t use Smartcards. The idea is to use a cryptochip on the
> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
> chip is on I2C bus and is e.g. accessible from Linux as a device.

OK... first question: why do you want certificates in hardware? 
What's the point in that?

Is there some kind of design requirement where you want to be able to
wipe and re-image the operating system storage, but leave the
*certificates* in the store intact? And even if it's that, isn't it
easier to just have separate storage for the certificates?

Here's a straw man proposal; tell me why/if it doesn't work for you.

Take an existing software PKCS#11 token, like SoftHSM or the NSS
softokn (which is entirely usable outside NSS; I was using it with
wpa_supplicant only a few hours ago). That's your certificate storage.

For keys though, this doesn't work — I assume you're here because you
really *do* want hardware security so that the private key can't be
copied away from the device; only used in situ.

For this, the TPM model works. Not the whole complex TSS stack, but
just the basic concept — you store your private keys in software, but
*encrypted*. With a key that only exists inside the hardware (and is
fairly much the *only* thing the hardware stores).

So when you want to perform an encrypt/decrypt/sign/verify operation
with a given key, you hand the encrypted key to the Atmel µc and ask
*it* to decrypt the key and then perform the operation. Optionally, it
can demand a PIN when you do so.

I'm not sure how well that would fit into OpenSC, but it does seem like
the low-effort way to achieving (what I assume to be) your
requirements.

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Dirk-Willem v. G. <di...@we...>]

And I would not underestimate how well a USB dongle with a smartcard/PKCS support works (if needed - use the type with a 4x1 pin IDC connector which can go straight onto the motherboard). And the integrate rather well with Java land (for client or server SSL certs; but certainly also all the way ‘up’ to a (very) low-volume HSM to use with something like EJBCA).

Going down that route also makes your tooling (on linux) easier than i2c (though we found doing an SSL engine for just signing over i2c quite easy*).

Dw.

*) The problem is that the NDA’s and licenses you need to enter into with the chip folks mean that you are then on the hook for the next N years to maintain such an engine on your own - no open source synergy. 

> On 14 Jun 2016, at 12:15, Andreas Schwier <and...@ca...> wrote:
> 
> Hi Peter,
> 
> I'd recommend to use a Secure Element platform like the NXP A700 which
> has a JavaCard Operating System and can run JavaCard applets
> implementing PKI functions.
> 
> That way you get an embedded smartcard controller that has the security
> attributes you are looking for. You could use one of the available
> JavaCard applets that work with OpenSC, e.g.
> 
> * the IsoApplet [2],
> * the myEID Applet [3] or
> * (of course) our SmartCard-HSM Applet [4].
> 
> If you want to go with the Atmel chip, integrating a stack smaller than
> OpenSC might be simpler. I'd recommend to take a look at our
> sc-hsm-embedded project, which is a lightweight PKCS#11 stack for
> embedded scenarios.
> 
> Andreas
> 
> 
> 
> [1]
> http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
> [2] https://github.com/philipWendland/IsoApplet
> [3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
> [4] http://www.smartcard-hsm.com/
> [5] https://github.com/CardContact/sc-hsm-embedded
> 
> On 06/14/2016 11:42 AM, Marx, Peter wrote:
>> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
>> 
>> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
>> 
>> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
>> 
>> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
>> 
>> 
>> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
>> 
>> -          Has this been done before ?
>> 
>> -          Can this be purchased or is it available for free ?
>> 
>> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
>> 
>> -          What effort would this be ?
>> 
>> -          In case there is no open solution: who knows a company which could deliver a solution ?
>> 
>> Peter
>> 
>> Knorr-Bremse IT-Services GmbH
>> Sitz: Muenchen
>> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
>> Registergericht Muenchen, HR B 167 268
>> 
>> This transmission is intended solely for the addressee and contains confidential information.
>> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
>> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are 
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
>> J-Flow, sFlow and other flows. Make informed decisions using capacity 
>> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>> 
>> 
>> 
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>> 
> 
> 
> -- 
> 
>    ---------    CardContact Systems GmbH
>   |.##> <##.|   Schülerweg 38
>   |#       #|   D-32429 Minden, Germany
>   |#       #|   Phone +49 571 56149
>   |'##> <##'|   http://www.cardcontact.de
>    ---------    Registergericht Bad Oeynhausen HRB 14880
>                 Geschäftsführer Andreas Schwier
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Andreas S. <and...@ca...>]

Hi Peter,

I'd recommend to use a Secure Element platform like the NXP A700 which
has a JavaCard Operating System and can run JavaCard applets
implementing PKI functions.

That way you get an embedded smartcard controller that has the security
attributes you are looking for. You could use one of the available
JavaCard applets that work with OpenSC, e.g.

* the IsoApplet [2],
* the myEID Applet [3] or
* (of course) our SmartCard-HSM Applet [4].

If you want to go with the Atmel chip, integrating a stack smaller than
OpenSC might be simpler. I'd recommend to take a look at our
sc-hsm-embedded project, which is a lightweight PKCS#11 stack for
embedded scenarios.

Andreas



[1]
http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
[2] https://github.com/philipWendland/IsoApplet
[3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
[4] http://www.smartcard-hsm.com/
[5] https://github.com/CardContact/sc-hsm-embedded

On 06/14/2016 11:42 AM, Marx, Peter wrote:
> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
> 
> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
> 
> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
> 
> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
> 
> 
> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
> 
> -          Has this been done before ?
> 
> -          Can this be purchased or is it available for free ?
> 
> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
> 
> -          What effort would this be ?
> 
> -          In case there is no open solution: who knows a company which could deliver a solution ?
> 
> Peter
> 
> Knorr-Bremse IT-Services GmbH
> Sitz: Muenchen
> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
> Registergericht Muenchen, HR B 167 268
> 
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
> 
> 
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 


-- 

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

[Opensc-devel] Crypto Chip Support imaginable ?

[Marx, P. <Pet...@kn...>]

I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.

But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.

I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.

Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:


-          What components have to be developped to make a cryptochip look as Smartcard to OpenSC

-          Has this been done before ?

-          Can this be purchased or is it available for free ?

-          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?

-          What effort would this be ?

-          In case there is no open solution: who knows a company which could deliver a solution ?

Peter

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. 
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: [Opensc-devel] Clarification request regarding the support of Yubikey Neo / 4

[Ryan C. <ry...@rc...>]

Jean-Pierre,

I'll add that if you are looking for a quick way to test, you can use the proof of concept I put together at https://github.com/ryanchapman/piv-pacs-poc
The security a full card management system provides is missing, but is good enough for quickly getting something that will work to test Windows auth, physical access control system, etc.
Card programming tested with Mac and Linux, and might also work on Windows with some effort.  Since it's off topic from opensc, please send support questions to me directly or open a GitHub issue.

Ryan

On May 28, 2016, at 8:38 PM, Douglas E Engert <dee...@gm...> wrote:

> 
> 
> On 5/28/2016 3:16 PM, Jean-Pierre Münch wrote:
>> Hello everyone,
>> 
>> I've searched the internet for quite some time now and couldn't find a satisfying / understandable answer, so I figured I could ask here.
>> 
>> I've read that the Yubikey 4 and the Yubikey Neo have a "PIV" application which is supported via OpenSC, so I really would like to have answers to the following (simple) questions:
>> 
>> What is the authoritative document / website that documents the procedure that enables the PIV application on the Yubikeys?
> 
> Getting the NEO to use the PIV application would be listed on the yubico.com web site.
> Note that the Yubikey was designed to do many different applications. Accessed by USB or NFC. 
> 
> https://developers.yubico.com/yubico-piv-tool/YubiKey_PIV_introduction.html
> https://developers.yubico.com/PIV/Tools/YubiKey_PIV_Manager.html
> https://www.yubico.com/why-yubico/for-individuals/computer-login/yubikey-neo-and-piv/
> 
> 
> The PIV application on the NEO is designed to implement the NIST 800-73 standards
> Google for NIST 800-73. 
> For PKCS#11 access  really the 800-73-3 part1 and part2. 
> 
> The Yubikey PIV Manager or yubico-piv-tool can then be used to generate keys on the NEO, and create certificate request and to load certificates. You need to supply the CA. 
> 
> https://github.com/OpenSC/OpenSC/wiki/US-PIV
> https://github.com/OpenSC/OpenSC/wiki/PivTool
> 
> The OpenSC piv-tool is a more basic tool that can do most of the above once you know the 3DES or AES key for the card. NIST did not standardize the functions needed by a Card Management system, so every  vendor's card is different. The User interface for using a card with certs and keys  already installed is standardized.
> 
>> Once the PIV application is enabled, is it possible to use the Yubikey as a normal PKCS#11 smart card, if not what operations (if any) are exposed via PKCS#11? (e.g. use the PKCS#11 library for signing and decrypting stuff on-card with RSA / ECDH / ECDSA)
> 
> Yes, you can do all of these NIST defines 4  certs/keys for the card. One for authentication, one for digital signature, RSA or ECDH, one for decryption/encryption (if EC can do key derivation ECDH) and a 4th cert/key that does not require a PIN, for the card to authenticate itself. Usable for door locks for example, and can be used over NFC. 
> 
>> Assuming you can use the Yubikey as an ordinary PKCS#11 smart card, does it support PKCS#11 (-tool) / PKCS#15 (-tool) / custom tool based key-import?
> 
> As I said, the NIST standards left card management up to the vendors. So generating keys, writing certificates and other objects are not supported by the OpenSC pkcs11-tool or pkcs15-tool. You need to use piv-tool or yubico-piv-tool. You also need to know the 3DES or AES key of the card to do any of the card management functions. The yubico-piv-tool can reset a NEO and load a new 3DES or AES key. 
> i.e. Yubikey was designed for an end user to initialize a card with their own keys and certs. 
> 
> P.S.
> Once you get at least the authentication cert/key and a CHUID, on the card you can use the card with windows without any otrher software. Windows comes with a PIV driver. The yubico-piv-tool can create a CHUID (which has a GUID.)
> 
>> 
>> I really hope you can help me with these three questions.
>> 
>> Best Regards
>> 
>> JPM
>> 
>> 
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are 
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
>> J-Flow, sFlow and other flows. Make informed decisions using capacity 
>> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>> 
>> 
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 
> -- 
> 
>  Douglas E. Engert  <DEE...@gm...>
>  
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] Clarification request regarding the support of Yubikey Neo / 4

[Douglas E E. <dee...@gm...>]

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/28/2016 3:16 PM, Jean-Pierre Münch
      wrote:<br>
    </div>
    <blockquote
      cite="mid:fed...@mu..."
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <p>Hello everyone,</p>
      <p>I've searched the internet for quite some time now and couldn't
        find a satisfying / understandable answer, so I figured I could
        ask here.</p>
      <p>I've read that the Yubikey 4 and the Yubikey Neo have a "PIV"
        application which is supported via OpenSC, so I really would
        like to have answers to the following (simple) questions:</p>
      <ul>
        <li>What is the authoritative document / website that documents
          the procedure that enables the PIV application on the
          Yubikeys?</li>
      </ul>
    </blockquote>
    <br>
    Getting the NEO to use the PIV application would be listed on the
    yubico.com web site.<br>
    Note that the Yubikey was designed to do many different
    applications. Accessed by USB or NFC. <br>
    <br>
<a class="moz-txt-link-freetext" href="https://developers.yubico.com/yubico-piv-tool/YubiKey_PIV_introduction.html">https://developers.yubico.com/yubico-piv-tool/YubiKey_PIV_introduction.html</a><br>
    <a class="moz-txt-link-freetext" href="https://developers.yubico.com/PIV/Tools/YubiKey_PIV_Manager.html">https://developers.yubico.com/PIV/Tools/YubiKey_PIV_Manager.html</a><br>
<a class="moz-txt-link-freetext" href="https://www.yubico.com/why-yubico/for-individuals/computer-login/yubikey-neo-and-piv/">https://www.yubico.com/why-yubico/for-individuals/computer-login/yubikey-neo-and-piv/</a><br>
    <br>
    <br>
    The PIV application on the NEO is designed to implement the NIST
    800-73 standards<br>
    Google for NIST 800-73. <br>
    For PKCS#11 access  really the 800-73-3 part1 and part2. <br>
    <br>
    The Yubikey PIV Manager or yubico-piv-tool can then be used to
    generate keys on the NEO, and create certificate request and to load
    certificates. You need to supply the CA. <br>
    <br>
    <a class="moz-txt-link-freetext" href="https://github.com/OpenSC/OpenSC/wiki/US-PIV">https://github.com/OpenSC/OpenSC/wiki/US-PIV</a><br>
    <a class="moz-txt-link-freetext" href="https://github.com/OpenSC/OpenSC/wiki/PivTool">https://github.com/OpenSC/OpenSC/wiki/PivTool</a><br>
    <br>
    The OpenSC piv-tool is a more basic tool that can do most of the
    above once you know the 3DES or AES key for the card. NIST did not
    standardize the functions needed by a Card Management system, so
    every  vendor's card is different. The User interface for using a
    card with certs and keys  already installed is standardized.<br>
    <br>
    <blockquote
      cite="mid:fed...@mu..."
      type="cite">
      <ul>
        <li>Once the PIV application is enabled, is it possible to use
          the Yubikey as a normal PKCS#11 smart card, if not what
          operations (if any) are exposed via PKCS#11? (e.g. use the
          PKCS#11 library for signing and decrypting stuff on-card with
          RSA / ECDH / ECDSA)</li>
      </ul>
    </blockquote>
    <br>
    Yes, you can do all of these NIST defines 4  certs/keys for the
    card. One for authentication, one for digital signature, RSA or
    ECDH, one for decryption/encryption (if EC can do key derivation
    ECDH) and a 4th cert/key that does not require a PIN, for the card
    to authenticate itself. Usable for door locks for example, and can
    be used over NFC. <br>
    <br>
    <blockquote
      cite="mid:fed...@mu..."
      type="cite">
      <ul>
        <li>Assuming you can use the Yubikey as an ordinary PKCS#11
          smart card, does it support PKCS#11 (-tool) / PKCS#15 (-tool)
          / custom tool based key-import?<br>
        </li>
      </ul>
    </blockquote>
    <br>
    As I said, the NIST standards left card management up to the
    vendors. So generating keys, writing certificates and other objects
    are not supported by the OpenSC pkcs11-tool or pkcs15-tool. You need
    to use piv-tool or yubico-piv-tool. You also need to know the 3DES
    or AES key of the card to do any of the card management functions.
    The yubico-piv-tool can reset a NEO and load a new 3DES or AES key.
    <br>
    i.e. Yubikey was designed for an end user to initialize a card with
    their own keys and certs. <br>
    <br>
    P.S.<br>
    Once you get at least the authentication cert/key and a CHUID, on
    the card you can use the card with windows without any otrher
    software. Windows comes with a PIV driver. The yubico-piv-tool can
    create a CHUID (which has a GUID.)<br>
    <br>
    <blockquote
      cite="mid:fed...@mu..."
      type="cite">
      <ul>
        <li> </li>
      </ul>
      <p>I really hope you can help me with these three questions.</p>
      <p>Best Regards</p>
      <p>JPM<br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. <a class="moz-txt-link-freetext" href="https://ad.doubleclick.net/ddm/clk/305295220;132659582;e">https://ad.doubleclick.net/ddm/clk/305295220;132659582;e</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="200">-- 

 Douglas E. Engert  <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm...">&lt;DEE...@gm...&gt;</a>
 
</pre>
  </body>
</html>

Re: [Opensc-devel] Clarification request regarding the support of Yubikey Neo / 4

[Vincent Le T. <vin...@my...>]

Hi,

You have to enable the CCID feature of the yubikey then enable the PIV
applet (not the default).
Last time I did it, it took me some times to find the right program.
Maybe this is this one:
https://www.yubico.com/products/services-software/personalization-tools/use/

regards,
Vincent

2016-05-28 22:16 GMT+02:00 Jean-Pierre Münch <ope...@mu...>:

> Hello everyone,
>
> I've searched the internet for quite some time now and couldn't find a
> satisfying / understandable answer, so I figured I could ask here.
>
> I've read that the Yubikey 4 and the Yubikey Neo have a "PIV" application
> which is supported via OpenSC, so I really would like to have answers to
> the following (simple) questions:
>
>    - What is the authoritative document / website that documents the
>    procedure that enables the PIV application on the Yubikeys?
>    - Once the PIV application is enabled, is it possible to use the
>    Yubikey as a normal PKCS#11 smart card, if not what operations (if any) are
>    exposed via PKCS#11? (e.g. use the PKCS#11 library for signing and
>    decrypting stuff on-card with RSA / ECDH / ECDSA)
>    - Assuming you can use the Yubikey as an ordinary PKCS#11 smart card,
>    does it support PKCS#11 (-tool) / PKCS#15 (-tool) / custom tool based
>    key-import?
>
> I really hope you can help me with these three questions.
>
> Best Regards
>
> JPM
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

[Opensc-devel] Clarification request regarding the support of Yubikey Neo / 4

[Jean-Pierre M. <ope...@mu...>]

Hello everyone,

I've searched the internet for quite some time now and couldn't find a
satisfying / understandable answer, so I figured I could ask here.

I've read that the Yubikey 4 and the Yubikey Neo have a "PIV"
application which is supported via OpenSC, so I really would like to
have answers to the following (simple) questions:

  * What is the authoritative document / website that documents the
    procedure that enables the PIV application on the Yubikeys?
  * Once the PIV application is enabled, is it possible to use the
    Yubikey as a normal PKCS#11 smart card, if not what operations (if
    any) are exposed via PKCS#11? (e.g. use the PKCS#11 library for
    signing and decrypting stuff on-card with RSA / ECDH / ECDSA)
  * Assuming you can use the Yubikey as an ordinary PKCS#11 smart card,
    does it support PKCS#11 (-tool) / PKCS#15 (-tool) / custom tool
    based key-import?

I really hope you can help me with these three questions.

Best Regards

JPM

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Mathias B. <ma...@br...>]

On Mon, May 23, 2016 at 12:52 PM, Douglas E Engert <dee...@gm...>
wrote:
>
> On 5/23/2016 9:10 AM, Jakub Jelen wrote:
> > On 05/23/2016 10:39 AM, Mathias Brossard wrote:
> >> On Mon, May 23, 2016 at 1:11 AM, Jakub Jelen <jj...@re...
> >> <mailto:jj...@re...>> wrote:
> >>
> >>     OpenSSH pkcs11 currently does not support EC keys and needs a lot of
> >>     changes to support them. There are at least two patches hanging
> around
> >>     openssh mailing lists and bugzillas adding this support to some
> >>     extent.
> >>     I plan to have a look into this in the months or so to get that
> >>     upstream.
> >>
> >>
> >> I'm the author of the one in #2474
> >> (https://bugzilla.mindrot.org/show_bug.cgi?id=2474), tell me if
> >> there's something I can do to help. The patch is tested with OpenSC
> >> (Yubikey Neo).
> > Yes. I tested your patch. Not that there would be something wrong, but I
> > would like to polish it and make it upstream. I started some comment on
> > this bug, but moved to other tasks so I will not be able to work on this
> > during next month.
>
> Keep in mind that OpenSSL-1.1.0 changes the EC structures that were used
> in 1.0.2.
> in before 1.1.0, there were ECDSA_METHOD and ECDH_METHOD. With 1.1.0
> there is only  EC_KEY_METHOD with with multiple routines.
>

True. I worked on it a little bit, but wasn't sure if updating my patch
before OpenSSL 1.1 is out was worth it. Hopefully with rc5 will be the last
time they change the APIs we need.

The OpenSC libp11 now has the opensc_engine built in and can run with
> OpenSSL versions 0.9.8 to 1.1.0.
>

I don't think OpenSSH would accept a patch to make it use libp11: too much
changes and license.

Sincerely,
-- 
Mathias Brossard

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Douglas E E. <dee...@gm...>]

On 5/23/2016 9:10 AM, Jakub Jelen wrote:
> On 05/23/2016 10:39 AM, Mathias Brossard wrote:
>> On Mon, May 23, 2016 at 1:11 AM, Jakub Jelen <jj...@re...
>> <mailto:jj...@re...>> wrote:
>>
>>     OpenSSH pkcs11 currently does not support EC keys and needs a lot of
>>     changes to support them. There are at least two patches hanging around
>>     openssh mailing lists and bugzillas adding this support to some
>>     extent.
>>     I plan to have a look into this in the months or so to get that
>>     upstream.
>>
>>
>> I'm the author of the one in #2474
>> (https://bugzilla.mindrot.org/show_bug.cgi?id=2474), tell me if
>> there's something I can do to help. The patch is tested with OpenSC
>> (Yubikey Neo).
> Yes. I tested your patch. Not that there would be something wrong, but I
> would like to polish it and make it upstream. I started some comment on
> this bug, but moved to other tasks so I will not be able to work on this
> during next month.

Keep in mind that OpenSSL-1.1.0 changes the EC structures that were used in 1.0.2.
in before 1.1.0, there were ECDSA_METHOD and ECDH_METHOD. With 1.1.0
there is only  EC_KEY_METHOD with with multiple routines.

The OpenSC libp11 now has the opensc_engine built in and can run with
OpenSSL versions 0.9.8 to 1.1.0.

>
> So far I tested with the NIST PIV Test cars, and I noticed a lot of
> "C_GetAttributeValue failed:" messages, which is very annoying.

What attributes are failing? RSA and EC keys have different attributes,
the code should request the CKA_KEY_TYPE first then query for attributes
based on the key type.

> Another
> consideration was using CKA_SIGN flags to test if the card even allows
> signatures using this key, but there will be probably more things to
> resolve.

That would be valid. With the NIST PIV specs, there are 4 cert/key defined,
and maybe multiple retired key management keys.
X.509 Certificate for PIV Authentication
X.509 Certificate for Digital Signature
X.509 Certificate for Key Management
X.509 Certificate for Card Authentication
Retired X.509 Certificates for Key Management

NIST does not define PKCS#11 attributes, but reading the NIST 800-73 usages
for these keys, the key Management private keys if RSA are to be used only for decrypt/unwrap
if EC they can only be used for derive. (But to allow a certificate request to be signed
by a key Management private key, the OpenSC code add the sign attribute if no cert is already
on the card.)

>
> Kind regards,
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Jakub J. <jj...@re...>]

On 05/23/2016 10:39 AM, Mathias Brossard wrote:
> On Mon, May 23, 2016 at 1:11 AM, Jakub Jelen <jj...@re... 
> <mailto:jj...@re...>> wrote:
>
>     OpenSSH pkcs11 currently does not support EC keys and needs a lot of
>     changes to support them. There are at least two patches hanging around
>     openssh mailing lists and bugzillas adding this support to some
>     extent.
>     I plan to have a look into this in the months or so to get that
>     upstream.
>
>
> I'm the author of the one in #2474 
> (https://bugzilla.mindrot.org/show_bug.cgi?id=2474), tell me if 
> there's something I can do to help. The patch is tested with OpenSC 
> (Yubikey Neo).
Yes. I tested your patch. Not that there would be something wrong, but I 
would like to polish it and make it upstream. I started some comment on 
this bug, but moved to other tasks so I will not be able to work on this 
during next month.

So far I tested with the NIST PIV Test cars, and I noticed a lot of 
"C_GetAttributeValue failed:" messages, which is very annoying. Another 
consideration was using CKA_SIGN flags to test if the card even allows 
signatures using this key, but there will be probably more things to 
resolve.

Kind regards,

-- 
Jakub Jelen
Security Technologies
Red Hat

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Douglas E E. <dee...@gm...>]

On 5/23/2016 3:11 AM, Jakub Jelen wrote:
> On 05/21/2016 04:09 PM, Douglas E Engert wrote:
>> Looking at the https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c
>> in pkcs11_rsa_private_encrypt is where it is failing. All of the pkcs#11 code does not assume
>> that a card may be removed. It might be easy to fix if the same card is inserted, but not
>> if a different card is inserted.
>>
>> Seeing the SPY trace would help a lot. (note that your PIN may be exposed in the trace).
>>
>> Most of the initial information about the card is obtained when ssh-add sends the message to ssh-agent
>> to register a new provider. But it may be some time before that is actually used from pkcs11_rsa_private_encrypt.
>> In pkcs11_rsa_private_encrypt:
>>    if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
>> is checking if the user should be logged_in from the last use of when the provider was first added to ssh_agent.
>> The C_Sign operation also uses si->session which may not be valid especially if a different card was inserted.
>>
>> I don't know if you are willing to make code changes or not, or to push the issue with OpenSSH.


> OpenSSH pkcs11 currently does not support EC keys and needs a lot of
> changes to support them. There are at least two patches hanging around
> openssh mailing lists and bugzillas adding this support to some extent.
> I plan to have a look into this in the months or so to get that upstream.

Yes, EC support is a separate issue which should be addressed.

>
> To the actual topic, if you think this is a valid use case (reinsertion
> of the card), I can pick that up and try to implement a fix. But I would
> need a bit help in the case "how to look for a reinsertion of the card"
> as mentioned in previous mails.


PKCS#11 can return CKR_DEVICE_REMOVED to indicate the card had been removed. From an opensc SPY trace
of ssh_agent:

55: C_Sign
2016-05-22 09:14:41.715
[in] hSession = 0x7fe7fb518580
[in] pData[ulDataLen] <REDACTED>
Returned:  50 CKR_DEVICE_REMOVED

Problem is this card status change is only returned to calling application when some attempt is made
to contact the card.  The way the ssh-agent code is written, where certificates and keys are found
when ssh-add registers the provider, but the key may not be used until a C_Sign is needed may be
minutes or hours later, and the user may have pulled his card/ID badge out when leaving the workstation
then inserted it upon return.
C_WaitForSlotEvent and C_getTokenInfo could be used to detect if the card status has changed before
doing the C_Sign.

Many PKCS#11 implementations will invalidate any sessions and release objects when the card is removed.

Insertion of the same card will also require C_Login to be done again. Even without removal and insertion
use of the card by other applications could also cause the PIN to be required again.

>
> The problem from my point of view is that you have a terminal/keyboard
> when you add the key (ssh-add, message adding a card to the agent
> already contains pin), but when you do the signature, you don't have it
> and you have basically no way to get the PIN from the user (unless you
> would store it in the ssh-agent, which is generally not a good idea;
> message to sign from ssh does not have any field to provide PIN).

Caching of the PIN is an option and OpenSC has optional pin caching.(Other PKCS#11 libs may not) But the removal of the card
will cause the opensc cache, slots, sessions and objects to be cleared. And a different card might be inserted requiring a different PIN!

The use of a PIN PAD reader is another option especially in a high security environment, and I see ssh-pkcs11.c supports
CKF_PROTECTED_AUTHENTICATION_PATH, so PIN is never in the host but user has access to pin pad reader even from ssh-agent but has to *look* at the pin pad reader.

But the issue of PKCS#11 slots, sessions and objects need to be reestablished would still need to be addressed.

So would a better way to address this would be scripts run from screen unlock or some user
started background process to do a new ssh-add -s?
i.e. when user pulls the card, they are most likely going to leave workstation, or don't want
the card being used for some reason.

Smart cards introduce a lot of human factors which are not often considered when writing code.



>
> Regards,
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Mathias B. <ma...@br...>]

On Mon, May 23, 2016 at 1:11 AM, Jakub Jelen <jj...@re...> wrote:

> OpenSSH pkcs11 currently does not support EC keys and needs a lot of
> changes to support them. There are at least two patches hanging around
> openssh mailing lists and bugzillas adding this support to some extent.
> I plan to have a look into this in the months or so to get that upstream.
>

I'm the author of the one in #2474 (
https://bugzilla.mindrot.org/show_bug.cgi?id=2474), tell me if there's
something I can do to help. The patch is tested with OpenSC (Yubikey Neo).

Sincerely,
--
Mathias Brossard

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Jakub J. <jj...@re...>]

On 05/21/2016 04:09 PM, Douglas E Engert wrote:
> Looking at the https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c
> in pkcs11_rsa_private_encrypt is where it is failing. All of the pkcs#11 code does not assume
> that a card may be removed. It might be easy to fix if the same card is inserted, but not
> if a different card is inserted.
>
> Seeing the SPY trace would help a lot. (note that your PIN may be exposed in the trace).
>
> Most of the initial information about the card is obtained when ssh-add sends the message to ssh-agent
> to register a new provider. But it may be some time before that is actually used from pkcs11_rsa_private_encrypt.
> In pkcs11_rsa_private_encrypt:
>    if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
> is checking if the user should be logged_in from the last use of when the provider was first added to ssh_agent.
> The C_Sign operation also uses si->session which may not be valid especially if a different card was inserted.
>
> I don't know if you are willing to make code changes or not, or to push the issue with OpenSSH.
OpenSSH pkcs11 currently does not support EC keys and needs a lot of 
changes to support them. There are at least two patches hanging around 
openssh mailing lists and bugzillas adding this support to some extent. 
I plan to have a look into this in the months or so to get that upstream.

To the actual topic, if you think this is a valid use case (reinsertion 
of the card), I can pick that up and try to implement a fix. But I would 
need a bit help in the case "how to look for a reinsertion of the card" 
as mentioned in previous mails.

The problem from my point of view is that you have a terminal/keyboard 
when you add the key (ssh-add, message adding a card to the agent 
already contains pin), but when you do the signature, you don't have it 
and you have basically no way to get the PIN from the user (unless you 
would store it in the ssh-agent, which is generally not a good idea; 
message to sign from ssh does not have any field to provide PIN).

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Matthew G. <gyu...@or...>]

Unfortunately I don't think I can provide a full trace. I have confirmed
my PIN is exposed, I could sanitize that. However, my cryptographic
knowledge is fairly weak and there is a lot of data in the trace that I
don't totally understand - I wouldn't feel comfortable sharing that with
internal review from a coworker. Are there specific sections I could
cherry-pick that may be useful?

I have requested a test card, but I'm skeptical I'll be able to obtain
one.

My C knowledge is weak, my cryptographic knowledge is weak, as is my
knowledge on smart cards. However, I can apply patches and compile code.
As a matter of fact, I just compiled the latest versions of  openssh and
opensc the other day without any issues.

Was there patch / code change you wanted me to try? I have no issues
with raising the problem with the OpenSSH project. My understanding of
the relationship between pcsc, opensc, and openssh is poor so I'm afraid
my technical contribution to this issue will be limited.

I appreciate the time you have taken on this issue so far.

Thank you,
Matthew

On 16-05-21 09:09:47, Douglas E Engert wrote:
> Looking at the https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c
> in pkcs11_rsa_private_encrypt is where it is failing. All of the pkcs#11 code does not assume
> that a card may be removed. It might be easy to fix if the same card is inserted, but not
> if a different card is inserted.
> 
> Seeing the SPY trace would help a lot. (note that your PIN may be exposed in the trace).
> 
> Most of the initial information about the card is obtained when ssh-add sends the message to ssh-agent
> to register a new provider. But it may be some time before that is actually used from pkcs11_rsa_private_encrypt.
> In pkcs11_rsa_private_encrypt:
>  if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
> is checking if the user should be logged_in from the last use of when the provider was first added to ssh_agent.
> The C_Sign operation also uses si->session which may not be valid especially if a different card was inserted.
> 
> I don't know if you are willing to make code changes or not, or to push the issue with OpenSSH.
> 
> 
> On 5/21/2016 7:30 AM, Matthew Gyurgyik wrote:
> >On 16-05-20 13:46:17, Douglas E Engert wrote:
> >>The problem maybe ssh_add has access to the environment variables,
> >>but it passes the name of the library  /usr/lib64/pkcs11-spy.so to the ssh-agent that
> >>then loads the library.  pkcs11-spy.so needs to then open the log and load the real PKCS#11 library
> >>so ssh-agent needs access to:
> >>export PKCS11SPY=/usr/lib64/opensc-pkcs11.so
> >>export PKCS11SPY_OUTPUT=/tmp/pkcs11-spy.$$.log
> >>
> >>Could also be full path to the logfile is needed in a directory writable like /tmp/pkcs11-spy.$$.log
> >>to get one log per process.
> >>
> >>
> >
> >Thanks for the pointer. I got pkcs11-spy working by setting those
> >environment variable when launching ssh-agent and running ssh-add and
> >using a full absolute path for the log.
> >
> >After removing the card I see the following error when trying to log
> >into SSH. Note I truncated some data just to be safe.
> >
> >53: C_Sign
> >2016-05-21 08:23:13.070
> >Returned:  257 CKR_USER_NOT_LOGGED_IN
> >
> >Is it up the application to detect CKR_USER_NOT_LOGGED_IN and take an
> >appropriate action? Is it possible to log into manually after
> >re-insertation?
> >
> >
> 
> -- 
> 
>  Douglas E. Engert  <DEE...@gm...>
> 
> 

-- 
Matthew Gyurgyik
HPC System Administrator
National Center for Computational Sciences
Oak Ridge National Laboratory
Bldg: 5600-D219 Phone: 865.576.7099

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Douglas E E. <dee...@gm...>]

Looking at the https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c
in pkcs11_rsa_private_encrypt is where it is failing. All of the pkcs#11 code does not assume
that a card may be removed. It might be easy to fix if the same card is inserted, but not
if a different card is inserted.

Seeing the SPY trace would help a lot. (note that your PIN may be exposed in the trace).

Most of the initial information about the card is obtained when ssh-add sends the message to ssh-agent
to register a new provider. But it may be some time before that is actually used from pkcs11_rsa_private_encrypt.
In pkcs11_rsa_private_encrypt:
  if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
is checking if the user should be logged_in from the last use of when the provider was first added to ssh_agent.
The C_Sign operation also uses si->session which may not be valid especially if a different card was inserted.

I don't know if you are willing to make code changes or not, or to push the issue with OpenSSH.


On 5/21/2016 7:30 AM, Matthew Gyurgyik wrote:
> On 16-05-20 13:46:17, Douglas E Engert wrote:
>> The problem maybe ssh_add has access to the environment variables,
>> but it passes the name of the library  /usr/lib64/pkcs11-spy.so to the ssh-agent that
>> then loads the library.  pkcs11-spy.so needs to then open the log and load the real PKCS#11 library
>> so ssh-agent needs access to:
>> export PKCS11SPY=/usr/lib64/opensc-pkcs11.so
>> export PKCS11SPY_OUTPUT=/tmp/pkcs11-spy.$$.log
>>
>> Could also be full path to the logfile is needed in a directory writable like /tmp/pkcs11-spy.$$.log
>> to get one log per process.
>>
>>
>
> Thanks for the pointer. I got pkcs11-spy working by setting those
> environment variable when launching ssh-agent and running ssh-add and
> using a full absolute path for the log.
>
> After removing the card I see the following error when trying to log
> into SSH. Note I truncated some data just to be safe.
>
> 53: C_Sign
> 2016-05-21 08:23:13.070
> Returned:  257 CKR_USER_NOT_LOGGED_IN
>
> Is it up the application to detect CKR_USER_NOT_LOGGED_IN and take an
> appropriate action? Is it possible to log into manually after
> re-insertation?
>
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Matthew G. <gyu...@or...>]

On 16-05-20 13:46:17, Douglas E Engert wrote:
> The problem maybe ssh_add has access to the environment variables,
> but it passes the name of the library  /usr/lib64/pkcs11-spy.so to the ssh-agent that
> then loads the library.  pkcs11-spy.so needs to then open the log and load the real PKCS#11 library
> so ssh-agent needs access to:
> export PKCS11SPY=/usr/lib64/opensc-pkcs11.so
> export PKCS11SPY_OUTPUT=/tmp/pkcs11-spy.$$.log
> 
> Could also be full path to the logfile is needed in a directory writable like /tmp/pkcs11-spy.$$.log
> to get one log per process.
> 
>

Thanks for the pointer. I got pkcs11-spy working by setting those
environment variable when launching ssh-agent and running ssh-add and
using a full absolute path for the log.

After removing the card I see the following error when trying to log
into SSH. Note I truncated some data just to be safe.

53: C_Sign
2016-05-21 08:23:13.070
Returned:  257 CKR_USER_NOT_LOGGED_IN

Is it up the application to detect CKR_USER_NOT_LOGGED_IN and take an
appropriate action? Is it possible to log into manually after
re-insertation?