Re: Best practice for managing BCFKS?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for managing BCFKS?

Ernie Kovak
Okay, I understand why nobody would be interested in replying to such a question. :)  So, I went to the Security Stackexchange web site and read everything tagged with "key-management". I figure my BCFKS keystore is the equivalent of a key, so it should be handled the same way. 

The best approach would be to load the key from a server that requires authentication and keep it in memory, as described in this OWASP talk by Daniel Somerfield.

And for server keys in general (not my use case), best practice seems to be a “security in depth” approach, adding layers of obstacles to make it hard to get to the keys. Store the keys separately from the data, and in encrypted form. The app fetches the encrypted keys on startup and keeps them encrypted in memory until needed, then decrypts the keys using a local key obtained from a config file. The config file is owned by a user other than the user under which the app is running so that a sudo is required to get to it. And more layers, and more layers... turtles all the way down. :)

Ernie

On Wed, Jan 31, 2018 at 3:00 PM, Ernie Kovak <[hidden email]> wrote:
Hello -

I need to use the Java BCFKS in a system where multiple thick clients need to share symmetric keys. I'm pretty new to this, and was wondering what is considered best practice for that. Copy the keystore around? Put the keystore on a network share or a server and load via KeyStore's load(InputStream method)?

If my users also need personal keys, can I load a second BCFKS from the local file system?

Thanks!
Ernie

Reply | Threaded
Open this post in threaded view
|

Re: Best practice for managing BCFKS?

Arshad Noor

Hi Ernie,

The reason you haven't seen responses on the forum is because this is a very hard problem.  While cryptography is a very intellectually stimulating field, what you're trying to solve is fairly challenging.  I've been doing cryptographic key-management for 19 years and I still feel humbled by what I don't know and actively support the Bouncy Castle folks for what they do.

Which is the reason why I hate doing what I'm about to do.  This forum is intended to be a place for learning about cryptography rather than about implementations.  But, I will do this just once in the hope that it might help those who may be looking for something more "ready-made" than what you described.  I also hope the forum will forgive me for this commercialism, because we are long-time fans of BC and open-source licensing - our meager contributions to the FOSS community are available on sourceforge.net.

Yes, if someone is so inclined they could tackle key-management themselves - or they could consider something like the StrongKey Tellaro which provides:

  • Common Criteria EAL4+ certified cryptographic hardware module for the root of all your keys;
  • Encryption and tokenization of structured data-elements (CHD, SSN, ACH, DOB, phone numbers, e-mail addresses, JSON, XML, etc.)
  • Key management for provisioning, escrow and recovery of cryptographic keys, keystores, P12 bags, etc.;
  • Card-present transaction processing using ANSI X9.24-1 (DUKPT) for end-to-end encryption;
  • FIDO Certified U2F server based strong-authentication;
  • FIDO-enabled single sign-on gateway to eliminate the use of passwords from legacy web-applications;
  • File-encryption integrated with AWS and Azure to store ciphertext in the cloud or on your network - keys always remain on the Tellaro;
  • End-user ready FIDO-enabled secure file-transfer web-application to share files without trusting cloud service providers for key-management;
  • High-availability with replication to multiple nodes - even across WANs - to enable active-active clustering;
  • Split-key knowledge control of cryptographic keys for compliance with PCI-DSS, HIPAA and other security regulations;
  • True random number generator from hardware;
  • Integration with corporate LDAP, AD and OAM for authorization control;
  • SOAP and REST webservices that enable integration in less than an hour (for the basic encryption/tokenization webservice);
  • 100 webservice transactions per second sustained throughput;
  • Storage for half-billion encrypted data-elements;
  • .... and more features coming in Q2.

Hardware, software (all FOSS licenses) and annual support for less than the price of a departmental printer.  Yes, enterprise-grade solutions that go beyond the Tellaro are also available, but in keeping with the spirit of FOSS communities that seek free or high-value-low-cost solutions, I've chosen to mention the Tellaro.

Thank you for your indulgence.  And now, back to the main program...

Arshad Noor
StrongAuth, Inc.


On 02/22/2018 10:24 AM, Ernie Kovak wrote:
Okay, I understand why nobody would be interested in replying to such a question. :)  So, I went to the Security Stackexchange web site and read everything tagged with "key-management". I figure my BCFKS keystore is the equivalent of a key, so it should be handled the same way. 

The best approach would be to load the key from a server that requires authentication and keep it in memory, as described in this OWASP talk by Daniel Somerfield.

And for server keys in general (not my use case), best practice seems to be a “security in depth” approach, adding layers of obstacles to make it hard to get to the keys. Store the keys separately from the data, and in encrypted form. The app fetches the encrypted keys on startup and keeps them encrypted in memory until needed, then decrypts the keys using a local key obtained from a config file. The config file is owned by a user other than the user under which the app is running so that a sudo is required to get to it. And more layers, and more layers... turtles all the way down. :)

Ernie

On Wed, Jan 31, 2018 at 3:00 PM, Ernie Kovak <[hidden email]> wrote:
Hello -

I need to use the Java BCFKS in a system where multiple thick clients need to share symmetric keys. I'm pretty new to this, and was wondering what is considered best practice for that. Copy the keystore around? Put the keystore on a network share or a server and load via KeyStore's load(InputStream method)?

If my users also need personal keys, can I load a second BCFKS from the local file system?

Thanks!
Ernie