BTW the interface I proposed wouldn't work with a HSM, they do the encryption/decryption on board don't they? So it would be something like:

public EncryptionProvider {

  public void generateKeys(RealmModel realm);

  public byte[] encrypt(byte[] b);

  public byte[] decrypt(byte[] b);

  public byte[] sign(byte[] b);

}

or something along those lines ;)

----- Original Message -----
> From: "Bruno Oliveira" <bruno@abstractj.org>
> To: "Bill Burke" <bburke@redhat.com>, "Stian Thorgersen" <stian@redhat.com>
> Cc: keycloak-dev@lists.jboss.org
> Sent: Thursday, 30 January, 2014 1:22:35 PM
> Subject: Re: [keycloak-dev] Storage protection
>

> I think that’s just fine, where developers will store their private keys is
> their decision: db, text file or fancy hardwares.
>
> My only suggestion is to generate these keys with some KDF function, maybe
> during the first application setup? What do you have in mind Stian? command
> line, web interface, integrate with jboss-cli?

First app startup I'd say. OOTB experience should be as simple as possible. Probably just bootstrap it in: https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java

and set the location to ${jboss.config.dir}/keycloak.secret or something?

>
> --
> abstractj
>
> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian@redhat.com) wrote:
> > > We should do it as an SPI to make it extensible. This would allow
> > admins to integrate it best into how they manage sensitive data.
> > I don't know what common practices are, but I imagine there are
> > many ways to do it.
> >
> > As I said before I think our options OOTB are either to just store
> > in clear-text, or generate a master password and write to a known
> > location (/standalone/data/realm.secret?).
> > Anything more than that would make it hard to use for development.
> >
> > I believe it is safer store a master password in a file (and an additional
> > layer of defence to storing in clear-text to RDBMS, which can
> > be compromised through SQL-injection attacks that non-shared
> > file systems are not prone to).
> >
> > The master password location can be configurable through a system
> > property. Admins can place this file on an encrypted location,
> > this would be recommended. I don't think its any better to provide
> > the master password as a argument or system property at startup
> > than it is to store it in a file on an encrypted drive. The reason
> > being is that if someone gains admin access to the server, they
> > will be able to read the file, sure, but they can also get the arguments
> > used to start the server just as easily. If the server is turned
> > of neither properties or an encrypted drive will help them. Admins
> > already have mechanisms in place to manage encrypted drives
> > on servers, so we'd rely on them to know how to do that themselves.
> >
> > For future and more improved solutions we can add whatever mechanisms
> > users are asking for through the SPI. Enterprises can also implement
> > their own.
> >
> > The SPI could be something as simple as:
> >
> > public interface PrivateKeyProvider {
> > public PEM getPrivateKey(RealmModel realm);
> > }
>
>