opencryptoki-users Mailing List for openCryptoki
Brought to you by:
ebarretto
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(7) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(3) |
2007 |
Jan
(14) |
Feb
|
Mar
|
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(10) |
Dec
(6) |
2008 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
(6) |
May
(3) |
Jun
(6) |
Jul
(10) |
Aug
(4) |
Sep
(17) |
Oct
(13) |
Nov
(43) |
Dec
(72) |
2009 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
|
2011 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(15) |
Mar
|
Apr
(1) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Harald F. <fr...@li...> - 2021-02-10 08:40:47
|
Yes ... but please, I don't know if locking works with volumes assigned to containers. So this works fine as long as the applications use it in a read-only fashion, but I am not sure if this also works when one of these containers does an update in the ock key store. Please be aware - this is not special to opencrpytoki - every 'statefull' container like database instances has this very same problem within a cluster. Maybe you read more about this in the kubernetes docu for statefull sets. On 09.02.21 18:46, Alan King wrote: > Thank you. So just to be sure - I can mount a shared filesystem on /var/lib/opencryptoki and the token key objects will be available to all containers sharing that filesystem. Is that correct? > > Alan > > > > Alan King > Financial Sciences > IBM Research > > > > ----- Original message ----- > From: "Harald Freudenberger" <fr...@li...> > To: Alan King/Watson/IBM@IBM, ope...@li... > Cc: > Subject: Re: [EXTERNAL] [opencryptoki-users] Using Opencryptoki in a docker container - serializing keys for stop (or crash!) and restart / restore > Date: Tue, Feb 9, 2021 9:36 AM > > Hello Alan > > hm, what do you mean with "recover keys" ? > > I assume you are referring to some kind of token key objects. > Opencryptoki has it's memory about keys in /var/lib/opencryptoki. > So you can for example customize your docker image with a prepared > /var/lib/opencryptoki and all ock objects stored in there are available > in your container instances. > > On 09.02.21 15:08, Alan King wrote: > > Hi all - a newbie here (who probably should read manuals more thoroughly). > > > > We are deploying a Cloud service that will use a Softhsm - just for development purposes. > > > > The question is whether there is a way to recover keys from storage. I see a migrate executable. > > Is that the way to do it? > > > > Thanks > > Alan > > > > > > > > > > Alan King > > Financial Sciences > > IBM Research > > > > > > > > _______________________________________________ > > opencryptoki-users mailing list > > ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opencryptoki-users > > > |
From: Alan K. <ki...@us...> - 2021-02-09 17:46:21
|
<div class="socmaildefaultfont" dir="ltr" style="font-family:Tahoma, Geneva, sans-serif;font-size:10pt" ><div dir="ltr" >Thank you. So just to be sure - I can mount a shared filesystem on /var/lib/opencryptoki and the token key objects will be available to all containers sharing that filesystem. Is that correct?</div> <div dir="ltr" > </div> <div dir="ltr" >Alan</div> <div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > <div><br><br>Alan King<br>Financial Sciences</div> <div>IBM Research</div></div></div></div></div></div></div></div></div> <div dir="ltr" > </div> <div dir="ltr" > </div> <blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Harald Freudenberger" <fr...@li...><br>To: Alan King/Watson/IBM@IBM, ope...@li...<br>Cc:<br>Subject: Re: [EXTERNAL] [opencryptoki-users] Using Opencryptoki in a docker container - serializing keys for stop (or crash!) and restart / restore<br>Date: Tue, Feb 9, 2021 9:36 AM<br> <div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >Hello Alan<br><br>hm, what do you mean with "recover keys" ?<br><br>I assume you are referring to some kind of token key objects.<br>Opencryptoki has it's memory about keys in /var/lib/opencryptoki.<br>So you can for example customize your docker image with a prepared<br>/var/lib/opencryptoki and all ock objects stored in there are available<br>in your container instances.<br><br>On 09.02.21 15:08, Alan King wrote:<br>> Hi all - a newbie here (who probably should read manuals more thoroughly).<br>> <br>> We are deploying a Cloud service that will use a Softhsm - just for development purposes.<br>> <br>> The question is whether there is a way to recover keys from storage. I see a migrate executable.<br>> Is that the way to do it?<br>> <br>> Thanks<br>> Alan<br>> <br>> <br>><br>><br>> Alan King<br>> Financial Sciences<br>> IBM Research<br>><br>><br>><br>> _______________________________________________<br>> opencryptoki-users mailing list<br>> ope...@li...<br>> <a href="https://lists.sourceforge.net/lists/listinfo/opencryptoki-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opencryptoki-users</a> </font></div></blockquote> <div dir="ltr" > </div></div><BR> |
From: Harald F. <fr...@li...> - 2021-02-09 14:36:58
|
Hello Alan hm, what do you mean with "recover keys" ? I assume you are referring to some kind of token key objects. Opencryptoki has it's memory about keys in /var/lib/opencryptoki. So you can for example customize your docker image with a prepared /var/lib/opencryptoki and all ock objects stored in there are available in your container instances. On 09.02.21 15:08, Alan King wrote: > Hi all - a newbie here (who probably should read manuals more thoroughly). > > We are deploying a Cloud service that will use a Softhsm - just for development purposes. > > The question is whether there is a way to recover keys from storage. I see a migrate executable. > Is that the way to do it? > > Thanks > Alan > > > > > Alan King > Financial Sciences > IBM Research > > > > _______________________________________________ > opencryptoki-users mailing list > ope...@li... > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_opencryptoki-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0b6NNH7cR9xuBaC6NQ-VDynd0pu3fSzDBIHhNgivNu8&m=bP1Rp8fdKC9RLU9uu9qvA6kG96b57UUwyNNPSHNaW6M&s=H4bq9u_qBnyp9yS2KNoaKW9bLXI4kHlo2FSAmsTQ-dI&e= |
From: Alan K. <ki...@us...> - 2021-02-09 14:08:21
|
<div class="socmaildefaultfont" dir="ltr" style="font-family:Tahoma, Geneva, sans-serif;font-size:10pt" ><div dir="ltr" >Hi all - a newbie here (who probably should read manuals more thoroughly).</div> <div dir="ltr" > </div> <div dir="ltr" >We are deploying a Cloud service that will use a Softhsm - just for development purposes.</div> <div dir="ltr" > </div> <div dir="ltr" >The question is whether there is a way to recover keys from storage. I see a migrate executable.</div> <div dir="ltr" >Is that the way to do it?</div> <div dir="ltr" > </div> <div dir="ltr" >Thanks</div> <div dir="ltr" >Alan</div> <div dir="ltr" > </div> <div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > <div><br><br>Alan King<br>Financial Sciences</div> <div>IBM Research</div></div></div></div></div></div></div></div></div></div><BR> |
From: David W. <dav...@se...> - 2019-01-08 01:21:10
|
Hello, I am updating a system with a TPM token created with opencryptoki 2.x to opencryptoki 3. After updating I cannot login to the token, however I can view a stored certificate that does not require login to view. I found the following in an IBM page discussing migration of CCA tokens from opencryptoki 2 to 3: "In openCryptoki version 2, private token objects are encrypted and decrypted with a secure key in the cryptographic adapter. In version 3, this encryption and decryption is done with a clear key using cryptographic software functions. *Therefore, **openCryptoki version 3 cannot decrypt a version 2 private token object."* Does anyone know if this applies to TPM tokens as well as CCA tokens? If so, is there a TPM token upgrade path similar to the pkcscca migration utility? Thanks, Dave |
From: Vinícius S. <vin...@gm...> - 2018-11-08 18:03:10
|
Hi, I'm starting to use Opencryptoki, so forgive me if I'm not well versed yet. Our HSM already had some keys created through direct CCA API, and I wanted to know if I can access them through Java (using Opencryptoki). The way I see it the repositories are different, cause their files are created in different places. Is there a way for me to configure Opencryptoki in such a way that keys created through direct CCA Api are shared with the Opencryptoki ones? Att. Vinicius Seufitele |
From: Eduardo B. <eba...@li...> - 2018-06-08 16:24:22
|
Hello all, Today we are releasing new versions of opencryptoki (3.10.0) and openssl-ibmca (2.0.0): 1. Opencryptoki 3.10.0 - Add support to ECC on ICA token and to common code. - Add SHA224 support to SOFT token. - Improve pkcsslotd logging. - Fix sha512_hmac_sign and rsa_x509_verify for ICA token. - Fix tracing of session id. - Fix and improve testcases. - Fix spec file permission for log directory. - Fix build warnings. Download: https://github.com/opencryptoki/opencryptoki/archive/v3.10.0.tar.gz 2. OpenSSL-ibmca (2.0.0) - Add ECC support. - Add check and distcheck make-targets. - Project cleanup, code was broken into multiple files and coding style cleanup. - Improvements to compat macros for openssl. - Don't disable libica sw fallbacks. - Fix dlclose logic. Download: https://github.com/opencryptoki/openssl-ibmca/archive/v2.0.0.tar.gz For more information, please check the Changelog and commit history of each project. In case of problems, please report to us in mailing list, direct email to me, or create a Github Issue. Thanks, Best regards, Eduardo |
From: Eduardo B. <eba...@li...> - 2018-06-08 15:24:22
|
Hello all, Today we are releasing new versions of opencryptoki (3.10.0) and openssl-ibmca (2.0.0): 1. Opencryptoki 3.10.0 - Add support to ECC on ICA token and to common code. - Add SHA224 support to SOFT token. - Improve pkcsslotd logging. - Fix sha512_hmac_sign and rsa_x509_verify for ICA token. - Fix tracing of session id. - Fix and improve testcases. - Fix spec file permission for log directory. - Fix build warnings. Download: https://github.com/opencryptoki/opencryptoki/archive/v3.10.0.tar.gz 2. OpenSSL-ibmca (2.0.0) - Add ECC support. - Add check and distcheck make-targets. - Project cleanup, code was broken into multiple files and coding style cleanup. - Improvements to compat macros for openssl. - Don't disable libica sw fallbacks. - Fix dlclose logic. Download: https://github.com/opencryptoki/openssl-ibmca/archive/v2.0.0.tar.gz For more information, please check the Changelog and commit history of each project. In case of problems, please report to us in mailing list, direct email to me, or create a Github Issue. Thanks, Best regards, Eduardo |
From: Eduardo B. <eba...@li...> - 2018-02-22 19:47:32
|
Hello all, Today we are making three new releases: 1. OpenCryptoki - 3.9.0 - Improve build flags - EP11 EC Key Import - Support CK_FALSE and CK_TRUE that was introduced in PKCS #11 v2.20 - EP11 Enhancements - Update broken links in documentation - Increase RSA max key length - Fix token reinitialization Download: Github:https://github.com/opencryptoki/opencryptoki/archive/v3.9.0.tar.gz SourceForge:http://downloads.sourceforge.net/opencryptoki/opencryptoki-3.9.0.tar.gz 2. OpenSSL-ibmca - 1.4.1 - Fix structure size for aes-256-ecb/cbc/cfb/ofb - Update man page - Switch to ibmca.so filename to allow standalone use - And other small fixes Download:https://github.com/opencryptoki/openssl-ibmca/archive/v1.4.1.tar.gz 3. OpenSSL-ibmpkcs11 - 1.0.2 - Fix RSA find of create private key - Switch to ibmpkcs11.so filename to allow standalone use - Link as a module - Remove obsolete m4s macro - Update spec file and .gitignore Download:https://github.com/opencryptoki/openssl-ibmpkcs11/archive/v1.0.2.tar.gz For more information, please check the Changelog and commit history of each project. Best regards, Eduardo |
From: Eduardo B. <eba...@li...> - 2017-11-23 15:43:24
|
Hello all, Today we are releasing a new minor version (3.8.2) of OpenCryptoki! This release includes: - Update man pages. - Improve ock_tests for parallel execution. - Fix FindObjectsInit for hidden HW-feature. - Fix to allow vendor defined hardware features. - Fix unresolved symbols for rpmbuild. - Fix tracing. - Code/project cleanup. For more information, please check the Changelog and commit history. You can easily grab this release in tarball format on Github or SourceForge: https://github.com/opencryptoki/opencryptoki/archive/v3.8.2.tar.gz http://downloads.sourceforge.net/opencryptoki/opencryptoki-3.8.2.tar.gz Regards, Eduardo |
From: Eduardo B. <eba...@li...> - 2017-10-30 19:42:28
|
Hello all, As we found a problem while building the project for the TPM token, we are releasing today a new version (3.8.1) of OpenCryptoki! This release includes: - Fix TPM data-structure reset function. - Fix error message when dlsym fails. - Update configure.ac For more information, please check the Changelog. You can easily grab this release in tarball format on Github or SourceForge: https://github.com/opencryptoki/opencryptoki/archive/v3.8.1.tar.gz http://downloads.sourceforge.net/opencryptoki/opencryptoki-3.8.1.tar.gz Thanks, |
From: Eduardo B. <eba...@li...> - 2017-10-27 12:44:59
|
Hello all, Today we are releasing a new version (3.8.0) of OpenCryptoki! This release includes: - Multi token instance feature. - Added switch to build opencryptoki locks (--enable-locks on configure step) instead of transactional memory (which is the default). - Updated documentation. - Bunch of small fixes. For more information, please check the Changelog. You can easily grab this release in tarball format on Github or SourceForge: https://github.com/opencryptoki/opencryptoki/archive/v3.8.0.tar.gz http://downloads.sourceforge.net/opencryptoki/opencryptoki-3.8.0.tar.gz Thanks, Eduardo |
From: Paulo R. P. V. <pv...@li...> - 2017-09-08 18:40:33
|
Hello all. It's a pleasure to announce that today we released the version 1.4.0 of the openssl-ibmca, an OpenSSL engine that uses the libica library under s390x to accelerate cryptographic operations. This version includes in addition to many bug fixes, these following major changes: - New license, now under Apache 2.0 - Support to AES-GCM - Updates in project and build files You can easily grab this release from GitHub: https://github.com/opencryptoki/openssl-ibmca/releases/tag/v1.4.0 I would like to thank and congratulate everyone who contributed to make this version a great release. Best regards, -- Paulo Ricardo Paz Vital Staff Software Engineer - Security Development IBM Linux Technology Center | Open Systems Development | IBM Systems |
From: Paulo R. P. V. <pv...@li...> - 2017-06-30 13:53:01
|
Hello all. It's a pleasure to announce that the migration of all opencryptoki projects was successfully completed today. All source code and bugs still open bugs were migrated to GitHub. The SourceForge has no longer bugs tracking neither source code repository, all information about the project was updated to point to GitHub and only the mailing lists will still be working. I'd like to thank you to everyone involved in this major task for the project. Let's code! Best regards, Paulo On 05/22/2017 01:13 PM, Paulo Ricardo Paz Vital wrote: > Hello all. > > Just a quick update on the migration of opencryptoki to GitHub. > > A new organization [1] was created, and most of the current contributors > were added (or invited to be part) in one of the following teams: > collaborators and/or maintainers. If you were not added or invited to be > part of one of the teams, please, send me your GitHub username and I can > add you. > > There, we have four new repositories [2], [3], [4] and [5], one for each > subproject. Starting now, SourceForge repositories are mirrors of these > GitHub repositories for a window of 30 working days. If nothing wrong > happens during this window, SourceForge repositories will be closed on > June, 30th 2017. > > Tomorrow we will going to start the analysis of current open bugs in > SourceForge and migrated to GitHub if necessary. > > [1] https://github.com/opencryptoki > [2] https://github.com/opencryptoki/opencryptoki > [3] https://github.com/opencryptoki/libica > [4] https://github.com/opencryptoki/openssl-ibmpkcs11 > [5] https://github.com/opencryptoki/openssl-ibmca > > > So, start to use the new repositories and have fun! > Thanks and best regards, > Paulo. > > On 05/22/2017 11:27 AM, Paulo Ricardo Paz Vital wrote: >> Hello All. >> >> Today we are executing a migration of all source code and bugs from >> SourceForge infrastructure to GitHub, under the organization [1]. The >> mailing lists and tarball repositories will continue under SourceForge >> infrastructure [2]. >> >> Today is planned to migrate users and source code. SourceForge >> repositories will be a mirror of the GitHub repositories for 30 days, >> and if nothing wrong happens until this time, they will be closed. >> >> All current open bugs will be analyzed and if there's no already >> solution on the code, they will be migrated (manually) to GitHub issues >> tracking for each repository created, otherwise they will be closed. >> >> Any updates during the migration phases will be announced here. >> >> [1] https://github.com/opencryptoki >> [2] https://sourceforge.net/projects/opencryptoki >> >> Thanks and best regards, >> > -- Paulo Ricardo Paz Vital Staff Software Engineer - Security Development IBM Linux Technology Center | Open Systems Development | IBM Systems |
From: Paulo R. P. V. <pv...@li...> - 2017-05-22 16:14:09
|
Hello all. Just a quick update on the migration of opencryptoki to GitHub. A new organization [1] was created, and most of the current contributors were added (or invited to be part) in one of the following teams: collaborators and/or maintainers. If you were not added or invited to be part of one of the teams, please, send me your GitHub username and I can add you. There, we have four new repositories [2], [3], [4] and [5], one for each subproject. Starting now, SourceForge repositories are mirrors of these GitHub repositories for a window of 30 working days. If nothing wrong happens during this window, SourceForge repositories will be closed on June, 30th 2017. Tomorrow we will going to start the analysis of current open bugs in SourceForge and migrated to GitHub if necessary. [1] https://github.com/opencryptoki [2] https://github.com/opencryptoki/opencryptoki [3] https://github.com/opencryptoki/libica [4] https://github.com/opencryptoki/openssl-ibmpkcs11 [5] https://github.com/opencryptoki/openssl-ibmca So, start to use the new repositories and have fun! Thanks and best regards, Paulo. On 05/22/2017 11:27 AM, Paulo Ricardo Paz Vital wrote: > Hello All. > > Today we are executing a migration of all source code and bugs from > SourceForge infrastructure to GitHub, under the organization [1]. The > mailing lists and tarball repositories will continue under SourceForge > infrastructure [2]. > > Today is planned to migrate users and source code. SourceForge > repositories will be a mirror of the GitHub repositories for 30 days, > and if nothing wrong happens until this time, they will be closed. > > All current open bugs will be analyzed and if there's no already > solution on the code, they will be migrated (manually) to GitHub issues > tracking for each repository created, otherwise they will be closed. > > Any updates during the migration phases will be announced here. > > [1] https://github.com/opencryptoki > [2] https://sourceforge.net/projects/opencryptoki > > Thanks and best regards, > -- Paulo Ricardo Paz Vital Staff Software Engineer - Security Development IBM Linux Technology Center | Open Systems Development | IBM Systems |
From: Paulo R. P. V. <pv...@li...> - 2017-05-22 14:27:22
|
Hello All. Today we are executing a migration of all source code and bugs from SourceForge infrastructure to GitHub, under the organization [1]. The mailing lists and tarball repositories will continue under SourceForge infrastructure [2]. Today is planned to migrate users and source code. SourceForge repositories will be a mirror of the GitHub repositories for 30 days, and if nothing wrong happens until this time, they will be closed. All current open bugs will be analyzed and if there's no already solution on the code, they will be migrated (manually) to GitHub issues tracking for each repository created, otherwise they will be closed. Any updates during the migration phases will be announced here. [1] https://github.com/opencryptoki [2] https://sourceforge.net/projects/opencryptoki Thanks and best regards, -- Paulo Ricardo Paz Vital Staff Software Engineer - Security Development IBM Linux Technology Center | Open Systems Development | IBM Systems |
From: Eduardo B. <eba...@li...> - 2017-04-27 13:50:37
|
Hello all, Today we are releasing a new version (3.7.0) of OpenCryptoki! This release includes: - Performance improvement. - Add ECDSA SHA2 support for CCA and EP11. - EP11 config file rework. - New Testcase for C_GetOperationState/C_SetOperationState. - Upgrade lincese to CPL-1.0. - Some bug fixes. For more information, please check the Changelog. You can easily grab this release in tarball format on SourceForge: http://downloads.sourceforge.net/opencryptoki/opencryptoki-3.7.0.tar.gz Thanks, Eduardo |
From: Eduardo B. <eba...@li...> - 2017-03-21 13:23:27
|
On 20-03-2017 19:27, John Paul Aguilar Rios wrote: > I have a problem with my tpm certificate/token on my chome os because I > was trying to find a way to use my chronos/localhost under crosh on > shell command and it wouldn't let me work on because it was asking me > for a password on the [sudo]. So how can I obtain this token/password > for [sudo] please help me out on letting me work on some projects on > chromium.org <http://chromium.org> > Hi John, Are you sure that your version of Chromium OS uses opencryptoki? I know that Chromium OS moved from opencryptoki to chaps (google's implementation of pkcs#11 for tpm only) https://github.com/google/chaps-linux Regards, Eduardo > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > opencryptoki-users mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencryptoki-users > |
From: John P. A. R. <rio...@gm...> - 2017-03-20 23:38:55
|
I have a problem with my tpm certificate/token on my chome os because I was trying to find a way to use my chronos/localhost under crosh on shell command and it wouldn't let me work on because it was asking me for a password on the [sudo]. So how can I obtain this token/password for [sudo] please help me out on letting me work on some projects on chromium.org |
From: Eduardo B. <eba...@li...> - 2016-10-18 13:10:37
|
Hi Thomas, The project has been changing administration on the last months. But I can guarantee that TPM2.0 is not in the roadmap for next year. If you are planning on developing or adding support to TPM2.0, patches are more than welcome. Best regards, Eduardo On 10-10-2016 14:16, Thomas Richard wrote: > Hello, > > > > I have a question about your roadmap. > > Did you plan something for TPM2.0 with PKCS#11 standard ?? > > > > Thanks and Regards, > > > > Thomas > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > opencryptoki-users mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencryptoki-users > |
From: Thomas R. <Tho...@ko...> - 2016-10-10 17:32:28
|
Hello, I have a question about your roadmap. Did you plan something for TPM2.0 with PKCS#11 standard ?? Thanks and Regards, Thomas |
From: Grzegorz S. <gst...@gm...> - 2016-09-29 10:53:05
|
Hi Osama, Thanks for the reply. I don't really understand how the keys could be used if I remove them from the disk. The certificate for the key is presented when connection parameters are negotiated, so as I see it, the private key needs then to be used to encrypt/decrypt the (symmeric) session key -- in other words, the private key neess to be available to the client software (OpenVPN, wpa_supplicant etc) so that encypted connections can be set up. If I remove it, the certificate will advertise a key I won't be able to use to set up encrypted connections. As I understand it, when I use the "TPM token" via openCryptoki, the private key of the new generated RSA key pair is stored on disk (under /var/lib/opencryptoki/tpm/[username]), but it's encrypted itself using one of the secure keys stored in the TPM chip -- otherwise the "TPM token" wouldn't be different from a relatively insecure software token. The key is then decrypted using the TPM key whenever it needs to be used. So, the trivial attack, as in "I get elevated privileges and snatch the /var/lib/opencryptoki/tpm files to clone the TPM token" shouldn't work, because the private key would be encrypted by keys from _this_ particular TPM chip and wouldn't work on another computer. And wouldn't even work for another user on the same computer without the user PIN number. This is how I see the situation: the CKA_EXTRACTABLE flag only means that you can set up a migration process as the TPM owner to transfer the key to another computer/TPM chip, having it securely encrypted all the way. To me, that's very different from "just take the file if you can and you've just extracted the key". Essentially, the extraction itself is a separate process that needs to be arranged by the TPM chip owner and happens at the "tpm-tools" level (or lower), that is, below the PKCS#11 API that openCryptoki provides. I wrote to the list to confirm that my understanding of the above is correct, or change it if it's incorrect, If I'm wrong about the security of the solution, the project will be stopped -- and has to be stopped, to minimize the risk of security breaches. So, this is pretty important to me. You're the only one to have replied so far, the list actually looks a bit like a tumbleweed and dust place. Which is odd, given that TPM-based security is certainly on the radar in a lot of places. Unfortunatly, I don't have any programmers' time assigned to the project, it's just a test rollout of Linux desktops, and our devs time is precious. I've posted to the -tech list as well, no reply from there either. Thanks for your time anyway, Best, Greg On 28 September 2016 at 12:24, Osama Farrag <of...@gm...> wrote: > Greg > > There is TPM based security, except it is not the best mode of TPM security. > if the key files are not on the disk then the clone attack vector is no > longer a concern; however, to fully address your project requirements, you > have to modify the source code of opencryptoki to make the key > non-migrate-able instead the currently hard coded setup. if you have > budget/time to do it, You should make the changes such that users of > opencryptoki be allowed through command line options, or configuration file, > to choose at the time of token/key generation to type of key > non-migrate-able, current default setting. This way each user can determine > decide what they need. This what should have been done in the first place. > There are also improvements needed; for example currently have certain > assumptions regarding password values that should be configurable to support > same defaults -z that TPM trousers assume. These will minimize difficulties > for many users. > > Best, > Osama > > On Wed, Sep 28, 2016 at 4:55 AM, Grzegorz Staniak <gst...@gm...> > wrote: >> >> Hi Osama, >> >> That's actually very bad news to me, as TPM-based security is a >> pre-condition of the project: if I can't get the setup to work with >> TPM, there will be no Linux laptop rollout at all. I haven't been able >> to find an alternative to openCryptoki as far as securing certificates >> and exposing them via PKCS#11 is concerned, so if not this, it's >> nothing. >> >> Thanks for your help, anyway. >> >> Best, >> Greg >> >> On 27 September 2016 at 18:35, Osama Farrag <of...@gm...> wrote: >> > Greg; >> > >> > Cloning the token is a feasible attack vector, given how openCryptoki >> > elected to implement TPM support; (hard code the type of keys TPM will >> > produce). The documents they provide recognizes this risk and recommend >> > that >> > key material to be removed/copied outside the host ideally to a machine >> > not >> > connected to a network. >> > >> > Please send an email when your blog site is up. >> > >> > Best regards >> > Osama Farrag >> > >> > On Tue, Sep 27, 2016 at 6:44 AM, Grzegorz Staniak <gst...@gm...> >> > wrote: >> >> >> >> Hi Osama, >> >> >> >> I'm not using CentOS or Red Hat (we went for Ubuntu LTS), and I'm not >> >> using OpenSSL either. I create a CSR using the "certtool" utility from >> >> the GNU TLS package, sign it on another system using the regular SSL >> >> CA setupo, then send it back and import into the "TPM token" using >> >> regular PKCS#11 tools (p11tool). I haven't got a detailed step-by-step >> >> write-up yet, but a blog entry is planned after I have all the setup >> >> in place, >> >> >> >> I agree that key migration is crucial for data protection, but in my >> >> case the keys used for wifi/vpn certificates can be provisioned again >> >> if lost or compromised, so I'm much more concerned about the >> >> possibility of "cloning" the virtual token. Is that a feasible vector >> >> o attack? What do I need to do to actually extract a private key from >> >> the TPM token and can this be done by the user if they have root >> >> access? I'm trying to research TPMs in more depth at the moment, but >> >> that's a broad subject. Can anyone advise? >> >> >> >> Best, >> >> Greg >> >> >> >> On 26 September 2016 at 19:14, Osama Farrag <of...@gm...> wrote: >> >> > Greg; >> >> > >> >> > >> >> > I am interested to know how you were able to get these parts working >> >> > of >> >> > “OpenCryptoki”? I am trying to get TPM keys to be signed by CA, but >> >> > was >> >> > not >> >> > able to setup OpenCryptoki to work with openSSL to generate CSR. I >> >> > understand the limitations/weakness caused by current approach taken >> >> > by >> >> > OpenCryptoki designers. >> >> > >> >> > >> >> > They should allowed users to select the type of key (with >> >> > non-migratble >> >> > as >> >> > an option); I think they were trying to simplify recovery of keys to >> >> > a >> >> > new >> >> > platform. They recommend that token removed from platform hard disk, >> >> > may >> >> > be >> >> > archived on media. I think recovery of Identity Key is not necessary >> >> > because >> >> > new key and certificate can be generated at a new platform. Not all >> >> > keys >> >> > are >> >> > storage keys, and as such ease of migration should be a users >> >> > choice. >> >> > >> >> > >> >> > Again, I hope that you have detailed steps for setting this for >> >> > CentOS >> >> > linux >> >> > distribution. >> >> > >> >> > >> >> > Thanks >> >> > >> >> > Osama Farrag >> >> > >> >> > The johns Hopkins University >> >> > >> >> > >> >> > -----Original Message----- >> >> > >> >> > From: Grzegorz Staniak <gst...@gm...> >> >> > >> >> > Date: Monday, September 26, 2016 at 6:12 AM >> >> > >> >> > To: "ope...@li..." >> >> > <ope...@li...> >> >> > >> >> > Subject: [opencryptoki-users] What does 'CKA_EXTRACTABLE' actually >> >> > mean? >> >> > >> >> > >> >> > using the >> >> > >> >> > tpm_tok backend, a CSR generated with the keys using 'certtool', >> >> > >> >> > signed externally, imported back into the "TPM token" with consistent >> >> > >> >> > names and IDs, almost ready for deployment. >> >> > >> >> > >> >> > My only worry is that when I list the objects in the token, the >> >> > >> >> > private key comes up flagged as: >> >> > >> >> > >> >> > CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_EXTRACTABLE; >> >> > >> >> > >> >> > I've found some info on the net that said openCryptoki generates >> >> > >> >> > "extractable" keys only. Taken literally, this signals a problem, >> >> > >> >> > since at least theoretically it means someone could clone the "TPM >> >> > >> >> > token". On the other hand, no standard PKCS#11 tool I've found allows >> >> > >> >> > that, exactly because it defeats the purpose of a token, TPM-based or >> >> > >> >> > not. >> >> > >> >> > >> >> > Could someone please answer the question from the subject to clear >> >> > >> >> > this up? Is a TPM-token key extractable using the PKCS#11 API, or >> >> > >> >> > otherwise? Can I prevent this using TPM tools? Thank you, >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Grzegorz Staniak <gstaniak [at] gmail _dot_ com> >> > >> > >> >> >> >> -- >> Grzegorz Staniak <gstaniak [at] gmail _dot_ com> > > -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com> |
From: Grzegorz S. <gst...@gm...> - 2016-09-28 08:55:53
|
Hi Osama, That's actually very bad news to me, as TPM-based security is a pre-condition of the project: if I can't get the setup to work with TPM, there will be no Linux laptop rollout at all. I haven't been able to find an alternative to openCryptoki as far as securing certificates and exposing them via PKCS#11 is concerned, so if not this, it's nothing. Thanks for your help, anyway. Best, Greg On 27 September 2016 at 18:35, Osama Farrag <of...@gm...> wrote: > Greg; > > Cloning the token is a feasible attack vector, given how openCryptoki > elected to implement TPM support; (hard code the type of keys TPM will > produce). The documents they provide recognizes this risk and recommend that > key material to be removed/copied outside the host ideally to a machine not > connected to a network. > > Please send an email when your blog site is up. > > Best regards > Osama Farrag > > On Tue, Sep 27, 2016 at 6:44 AM, Grzegorz Staniak <gst...@gm...> > wrote: >> >> Hi Osama, >> >> I'm not using CentOS or Red Hat (we went for Ubuntu LTS), and I'm not >> using OpenSSL either. I create a CSR using the "certtool" utility from >> the GNU TLS package, sign it on another system using the regular SSL >> CA setupo, then send it back and import into the "TPM token" using >> regular PKCS#11 tools (p11tool). I haven't got a detailed step-by-step >> write-up yet, but a blog entry is planned after I have all the setup >> in place, >> >> I agree that key migration is crucial for data protection, but in my >> case the keys used for wifi/vpn certificates can be provisioned again >> if lost or compromised, so I'm much more concerned about the >> possibility of "cloning" the virtual token. Is that a feasible vector >> o attack? What do I need to do to actually extract a private key from >> the TPM token and can this be done by the user if they have root >> access? I'm trying to research TPMs in more depth at the moment, but >> that's a broad subject. Can anyone advise? >> >> Best, >> Greg >> >> On 26 September 2016 at 19:14, Osama Farrag <of...@gm...> wrote: >> > Greg; >> > >> > >> > I am interested to know how you were able to get these parts working of >> > “OpenCryptoki”? I am trying to get TPM keys to be signed by CA, but was >> > not >> > able to setup OpenCryptoki to work with openSSL to generate CSR. I >> > understand the limitations/weakness caused by current approach taken by >> > OpenCryptoki designers. >> > >> > >> > They should allowed users to select the type of key (with non-migratble >> > as >> > an option); I think they were trying to simplify recovery of keys to a >> > new >> > platform. They recommend that token removed from platform hard disk, may >> > be >> > archived on media. I think recovery of Identity Key is not necessary >> > because >> > new key and certificate can be generated at a new platform. Not all keys >> > are >> > storage keys, and as such ease of migration should be a users choice. >> > >> > >> > Again, I hope that you have detailed steps for setting this for CentOS >> > linux >> > distribution. >> > >> > >> > Thanks >> > >> > Osama Farrag >> > >> > The johns Hopkins University >> > >> > >> > -----Original Message----- >> > >> > From: Grzegorz Staniak <gst...@gm...> >> > >> > Date: Monday, September 26, 2016 at 6:12 AM >> > >> > To: "ope...@li..." >> > <ope...@li...> >> > >> > Subject: [opencryptoki-users] What does 'CKA_EXTRACTABLE' actually mean? >> > >> > >> > using the >> > >> > tpm_tok backend, a CSR generated with the keys using 'certtool', >> > >> > signed externally, imported back into the "TPM token" with consistent >> > >> > names and IDs, almost ready for deployment. >> > >> > >> > My only worry is that when I list the objects in the token, the >> > >> > private key comes up flagged as: >> > >> > >> > CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_EXTRACTABLE; >> > >> > >> > I've found some info on the net that said openCryptoki generates >> > >> > "extractable" keys only. Taken literally, this signals a problem, >> > >> > since at least theoretically it means someone could clone the "TPM >> > >> > token". On the other hand, no standard PKCS#11 tool I've found allows >> > >> > that, exactly because it defeats the purpose of a token, TPM-based or >> > >> > not. >> > >> > >> > Could someone please answer the question from the subject to clear >> > >> > this up? Is a TPM-token key extractable using the PKCS#11 API, or >> > >> > otherwise? Can I prevent this using TPM tools? Thank you, >> > >> > >> >> >> >> -- >> Grzegorz Staniak <gstaniak [at] gmail _dot_ com> > > -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com> |
From: Grzegorz S. <gst...@gm...> - 2016-09-27 10:45:38
|
Hi Osama, I'm not using CentOS or Red Hat (we went for Ubuntu LTS), and I'm not using OpenSSL either. I create a CSR using the "certtool" utility from the GNU TLS package, sign it on another system using the regular SSL CA setupo, then send it back and import into the "TPM token" using regular PKCS#11 tools (p11tool). I haven't got a detailed step-by-step write-up yet, but a blog entry is planned after I have all the setup in place, I agree that key migration is crucial for data protection, but in my case the keys used for wifi/vpn certificates can be provisioned again if lost or compromised, so I'm much more concerned about the possibility of "cloning" the virtual token. Is that a feasible vector o attack? What do I need to do to actually extract a private key from the TPM token and can this be done by the user if they have root access? I'm trying to research TPMs in more depth at the moment, but that's a broad subject. Can anyone advise? Best, Greg On 26 September 2016 at 19:14, Osama Farrag <of...@gm...> wrote: > Greg; > > > I am interested to know how you were able to get these parts working of > “OpenCryptoki”? I am trying to get TPM keys to be signed by CA, but was not > able to setup OpenCryptoki to work with openSSL to generate CSR. I > understand the limitations/weakness caused by current approach taken by > OpenCryptoki designers. > > > They should allowed users to select the type of key (with non-migratble as > an option); I think they were trying to simplify recovery of keys to a new > platform. They recommend that token removed from platform hard disk, may be > archived on media. I think recovery of Identity Key is not necessary because > new key and certificate can be generated at a new platform. Not all keys are > storage keys, and as such ease of migration should be a users choice. > > > Again, I hope that you have detailed steps for setting this for CentOS linux > distribution. > > > Thanks > > Osama Farrag > > The johns Hopkins University > > > -----Original Message----- > > From: Grzegorz Staniak <gst...@gm...> > > Date: Monday, September 26, 2016 at 6:12 AM > > To: "ope...@li..." > <ope...@li...> > > Subject: [opencryptoki-users] What does 'CKA_EXTRACTABLE' actually mean? > > > using the > > tpm_tok backend, a CSR generated with the keys using 'certtool', > > signed externally, imported back into the "TPM token" with consistent > > names and IDs, almost ready for deployment. > > > My only worry is that when I list the objects in the token, the > > private key comes up flagged as: > > > CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_EXTRACTABLE; > > > I've found some info on the net that said openCryptoki generates > > "extractable" keys only. Taken literally, this signals a problem, > > since at least theoretically it means someone could clone the "TPM > > token". On the other hand, no standard PKCS#11 tool I've found allows > > that, exactly because it defeats the purpose of a token, TPM-based or > > not. > > > Could someone please answer the question from the subject to clear > > this up? Is a TPM-token key extractable using the PKCS#11 API, or > > otherwise? Can I prevent this using TPM tools? Thank you, > > -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com> -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com> |
From: Grzegorz S. <gst...@gm...> - 2016-09-26 10:12:34
|
Hi all, I'm preparing a rollout of Linux laptops for my company, and I need follow company policies with respect to security. Our Wiindows laptops use the TPM chip as a "virtual token" to secure configurations through the use of TPM-based keys in wifi and VPN configurations, accessed via the PKCS#11 API. I'm re-creating a similar setup under Linux, and I've managed to prepare the whole stack, with keys generated using the tpm_tok backend, a CSR generated with the keys using 'certtool', signed externally, imported back into the "TPM token" with consistent names and IDs, almost ready for deployment. My only worry is that when I list the objects in the token, the private key comes up flagged as: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_EXTRACTABLE; I've found some info on the net that said openCryptoki generates "extractable" keys only. Taken literally, this signals a problem, since at least theoretically it means someone could clone the "TPM token". On the other hand, no standard PKCS#11 tool I've found allows that, exactly because it defeats the purpose of a token, TPM-based or not. Could someone please answer the question from the subject to clear this up? Is a TPM-token key extractable using the PKCS#11 API, or otherwise? Can I prevent this using TPM tools? Thank you, Best regards, Greg -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com> |