[keycloak-dev] Storage protection

[Stian Thorgersen]

Just to clarify, the interface was just a mock-up to explain things, and not a proposal ;)

I'd imagine that'd it'd be up to the provider of the EncryptionProvider to generate (and store the key). So again mock-up code:


public MasterFileEncryptionProvider implements EncryptionProvider {

  public void generateKeys(RealmModel realm) {
    KeyPair keyPair = generateKeyPair();
    
    String pass = getOrCreateMasterPass(System.getProperty("keycloak.secret.file"));

    String encryptedPrivateKey = encryptKey(keyPair.getPrivate());

    realm.setPrivateKey(encryptedPrivateKey);
    realm.setPublicKey(keyPair.getPublic());
  }

  ...

}


Does that make sense?


----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 2:01:45 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> Sorry if my e-mail gave to you a wrong impression. I was just asking about
> the interface to generate the secret.
> 
> 
> On Thu, Jan 30, 2014 at 11:51 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > 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 at abstractj.org>
> > > To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <
> > stian at redhat.com>
> > > Cc: keycloak-dev at 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 at 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);
> > > > }
> > >
> > >
> >
> 
> 
> 
> --
> 
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>