[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] RE: Migrating Bouncy Castle keypairs to FIPS 140-2 compliant key store BCFKS
From:       David Hook <dgh () cryptoworkshop ! com>
Date:       2019-09-16 7:05:42
Message-ID: 089a9f46-a056-5161-6461-5e6f7a07b939 () cryptoworkshop ! com
[Download RAW message or body]


Actually the module does validate keys on import - there's a bit written
about how and why to do this in the NIST special publications. Of
course, that doesn't prevent some external app from doing something
improper with one of the keys either now or in the past or future. In
that respect if you are trying to migrate to FIPS compliance it is
better to rekey if you can, then you can be sure that whatever your new
security policy turns out to be, your keys have only been used in
accordance with it.

Regards,

David

On 16/9/19 4:41 pm, Eckenfels. Bernd wrote:
> Strictly speaking, if you do not create a key with a compliant solution, the key is \
> not compliant. However unless it has glaring security weakness you cannot see if \
> the key is generated with a compliant solution or not. 
> However if you aim for a compliant solution and maybe even need to certify this, \
> why not take the opportunity and rekey. 
> (Of course in most cases FIPS 140-2 level 1 is just a security theatre, in that \
> case nobody cares about things like usage restrictions (csr selfsigning) or \
> imported key material.) 
> Gruss
> Bernd
> --
> http://www.seeburger.com
> ________________________________________
> From: Prateek Kumar [Prateek.Kumar@nextlabs.com]
> Sent: Monday, September 16, 2019 04:24
> To: dev-crypto@bouncycastle.org
> Subject: [dev-crypto] Migrating Bouncy Castle keypairs to FIPS 140-2 compliant key \
> store BCFKS 
> --------------------------------------------------------------
> From: Prateek Kumar <Prateek.Kumar@nextlabs.com>
> To: dev-crypto@bouncycastle.org<mailto:dev-crypto@bouncycastle.org>
> Subject: Migrating Bouncy Castle keypairs to FIPS 140-2 compliant key store BCFKS
> 
> Hi,
> 
> Could anyone please advise on this requirement for our Java-webapp.
> 
> We have created keypairs (RSA and DH) using the non-FIPS Bouncy Castle provider in \
> a .bks keystores, and now we are trying to replace the provider with the FIPS 140-2 \
> compliant BC FIPS at https://downloads.bouncycastle.org/fips-java/bc-fips-1.0.2.jar \
>  For an existing deployment containing these keypairs in .bks (which already exist) \
> is there any way to: 
> * Migrate them into .bcfks keystores which is the compliant keystore (and any code \
> samples to do so). 
> * "Convert" these keypairs (with same algorithms/mode/padding/keysizes as the ones \
> chosen at creation time were already compliant, but created using standard Bouncy \
> Castle jars) into versions that would be FIPS compliant, or as if they'd been \
> created with the BC FIPS version. I don't know if this is possible and in \
> documentation at https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf \
> (Page 66 Appendix E), all I'm seeing is converting between JCE keypairs to \
> low-level FIPS key-primitives. 
> Thanks,
> Prateek Kumar
> --------------------------------------------------------------
> 
> 
> ---------------------------------------------------------------------
> STATEMENT OF CONFIDENTIALITY
> 
> The information contained in this electronic message and any attachments to this \
> message are intended for the exclusive use of the addressee(s) and may contain \
> confidential or privileged information. No representation is made on its accuracy \
> or completeness of the information contained in this electronic message. Certain \
> assumptions may have been made in the preparation of this material as at this date, \
> and are subject to change without notice. If you are not the intended recipient, \
> you are hereby notified that any dissemination, distribution or copying of this \
> e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at \
> NextLabs Inc and destroy all copies of this message and any attachments from your \
> system. ====================================================================== 
> 
> 
> 
> 
> 
> 
> 
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael \
> Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER \
>                 Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial \
>                 Register:
> e-mail: info@seeburger.de               HRB 240708 Mannheim
> 
> 
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und \
> kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. \
> Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und \
> stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind \
> Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und \
> jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher \
> Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der \
> Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer \
> Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen. 
> 
> This email is intended only for the recipient(s) to whom it is addressed. This \
> email may contain confidential material that may be protected by professional \
> secrecy. Any fact or opinion contained, or expression of the material herein, does \
> not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if \
> you have received this email in error, any use, publication or distribution \
> including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER \
> AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your \
> responsibility to check this email and its attachments for viruses. 


[prev in list] [next in list] [prev in thread] [next in thread]