3:43 p.m.
Good morning, I've been thinking about how to properly protect private key in a world
where HSM is not an option. Currently a key pair is generated
(https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac...)
to cryptographically sign tokens
(https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78eff...)
and the private key is stored into the database.
Some of the possibilities to improve it:
# 1
- HSM or Java Security manager are perfect, but impractical for regular devs, that would
require a lot of maintanance (a dream)
# 2
- Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that
someone would be required to enter the password at each app startup
# 3
- Not bullet-proof solution, but store the key into a text file that only sysadmins and
the web server has access, doing our best with the usage of ACLs provided by environment.
I understand Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same
time, a file could have a very restricted access while the database is more acessible to
developers.
-
# 4
Generate the keys per session, instead of use it per realm (it must be tested/implemented
because that could slow down our server)
# 5
Leave it as is.
So what do you think? Ideas or tomatoes?
--
abstractj
4:28 p.m.
It is going to be a choice between usability and protection.
Security sensitive deployments are going to be using HSM and vaulted
networks.
For everybody else, best is to go with usability thereby choosing an
approach that gives good-enough security.
One of the challenges we have faced is the non-availability of a
database for default deployments and the use of filesystem as the
default mechanism for storage. In the case of KeyCloak, it is using the
DB as the storage mechanism.
On 01/27/2014 08:43 AM, Bruno Oliveira wrote:
Good morning, I've been thinking about how to properly protect
private key in a world where HSM is not an option. Currently a key pair is generated
(https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac...)
to cryptographically sign tokens
(https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78eff...)
and the private key is stored into the database.
Some of the possibilities to improve it:
# 1
- HSM or Java Security manager are perfect, but impractical for regular devs, that would
require a lot of maintanance (a dream)
# 2
- Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that
someone would be required to enter the password at each app startup
# 3
- Not bullet-proof solution, but store the key into a text file that only sysadmins and
the web server has access, doing our best with the usage of ACLs provided by environment.
I understand Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same
time, a file could have a very restricted access while the database is more acessible to
developers.
-
# 4
Generate the keys per session, instead of use it per realm (it must be tested/implemented
because that could slow down our server)
# 5
Leave it as is.
So what do you think? Ideas or tomatoes?
--
abstractj
4:53 p.m.
On 1/27/2014 10:28 AM, Anil Saldhana wrote:
It is going to be a choice between usability and protection.
Security sensitive deployments are going to be using HSM and vaulted
networks.
For everybody else, best is to go with usability thereby choosing an
approach that gives good-enough security.
One of the challenges we have faced is the non-availability of a
database for default deployments and the use of filesystem as the
default mechanism for storage. In the case of KeyCloak, it is using the
DB as the storage mechanism.
I will throw out my red BS flag!...Can't see anybody seriously
considering using a flat file for production systems. There's no
reason you can't have a local-only, locked down DB with either HQL,
Mongo, or one of the other better Java databases. But anyways, Keycloak
only uses RDBMS by default, it has an SPI, and there's still the
Picketlink IDM API option available to us which we're going to seriously
consider after all major features have been implemented and we've
planned comprehensively about federation and scalability.
More comments inline responding to Bruno's email:
> # 1
> - HSM or Java Security manager are perfect, but impractical for regular devs, that
would require a lot of maintanance (a dream)
>
What is HSM? How could the Java Security Manager protect clear text
private keys and OTP keys?
> # 2
> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that
someone would be required to enter the password at each app startup
>
> # 3
>
> - Not bullet-proof solution, but store the key into a text file that only sysadmins
and the web server has access, doing our best with the usage of ACLs provided by
environment. I understand Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same
time, a file could have a very restricted access while the database is more acessible to
developers.
> -
Stian suggested having an SPI for this sort of feature. Either a
password would be required at Keycloak server startup, or the password
would be stored in a property file.
> # 4
>
> Generate the keys per session, instead of use it per realm (it must be
tested/implemented because that could slow down our server)
>
Not sure this is feasible. In a clustered environment, you'd need a
trusted way of transmitting all the realm keys. You also would need a
way to transmit the public key of the realm to each adapter. Each
adapter could make an HTTPS call on bootup to retrieve all relevant
realm metadata, but you'd still have to provide a truststore for the
adapter so it could make a trusted HTTPS call that verified the keycloak
server's host. But maybe we need this truststore irregardless :) ???
But, this still doesn't protect clear text OTP keys (i.e. "What is your
mother's maiden name?")
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:30 p.m.
On 01/27/2014 09:53 AM, Bill Burke wrote:
On 1/27/2014 10:28 AM, Anil Saldhana wrote:
> It is going to be a choice between usability and protection.
>
> Security sensitive deployments are going to be using HSM and vaulted
> networks.
>
> For everybody else, best is to go with usability thereby choosing an
> approach that gives good-enough security.
>
> One of the challenges we have faced is the non-availability of a
> database for default deployments and the use of filesystem as the
> default mechanism for storage. In the case of KeyCloak, it is using the
> DB as the storage mechanism.
>
I will throw out my red BS flag!...Can't see anybody seriously
considering using a flat file for production systems. There's no
reason you can't have a local-only, locked down DB with either HQL,
Mongo, or one of the other better Java databases. But anyways, Keycloak
only uses RDBMS by default, it has an SPI, and there's still the
Picketlink IDM API option available to us which we're going to seriously
consider after all major features have been implemented and we've
planned comprehensively about federation and scalability.
Typically in production
systems, the choice of storage is DB or LDAP.
That is when a stronger strategy such as HSM (Hardware Security Module)
is used.
http://en.wikipedia.org/wiki/Hardware_security_module
But for development purposes, a DB may not be available as the default
mechanism. In the case of WildFly AS, I am unsure if they ship with a
default DB
anymore.
More comments inline responding to Bruno's email:
>> # 1
>> - HSM or Java Security manager are perfect, but impractical for regular devs,
that would require a lot of maintanance (a dream)
>>
What is HSM? How could the Java Security Manager protect clear text
private keys and OTP keys?
>> # 2
>> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming
that someone would be required to enter the password at each app startup
>>
>> # 3
>>
>> - Not bullet-proof solution, but store the key into a text file that only
sysadmins and the web server has access, doing our best with the usage of ACLs provided by
environment. I understand Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same
time, a file could have a very restricted access while the database is more acessible to
developers.
>> -
Stian suggested having an SPI for this sort of feature. Either a
password would be required at Keycloak server startup, or the password
would be stored in a property file.
>> # 4
>>
>> Generate the keys per session, instead of use it per realm (it must be
tested/implemented because that could slow down our server)
>>
Not sure this is feasible. In a clustered environment, you'd need a
trusted way of transmitting all the realm keys. You also would need a
way to transmit the public key of the realm to each adapter. Each
adapter could make an HTTPS call on bootup to retrieve all relevant
realm metadata, but you'd still have to provide a truststore for the
adapter so it could make a trusted HTTPS call that verified the keycloak
server's host. But maybe we need this truststore irregardless :) ???
But, this still doesn't protect clear text OTP keys (i.e. "What is your
mother's maiden name?")
5:34 p.m.
On 1/27/2014 11:30 AM, Anil Saldhana wrote:
But for development purposes, a DB may not be available as the
default
mechanism. In the case of WildFly AS, I am unsure if they ship with a
default DB
anymore.
Wildfly still has a DB, and we use it by default.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:47 p.m.
Hi Bill, some answers inline. I forgot to add references.
--
abstractj
On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke(a)redhat.com) wrote:
> More comments inline responding to Bruno's email:
>> # 1
>> - HSM or Java Security manager are perfect, but impractical
for regular devs, that would require a lot of maintanance (a dream)
>>
What is HSM? How could the Java Security Manager protect clear
http://en.wikipedia.org/wiki/Hardware_security_module
text
private keys and OTP keys?
With Java Security Manager is possible to restrict code privileges to the resource
specified
(https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Appli...).
>> # 2
>> - Entering a password for a PKCS#8/PBKDF2-derived key, also
impractical assuming that someone would be required to enter
the password at each app startup
>>
>> # 3
>>
>> - Not bullet-proof solution, but store the key into a text file
that only sysadmins and the web server has access, doing our best
with the usage of ACLs provided by environment. I understand
Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html)
but at the same time, a file could have a very restricted access
while the database is more acessible to developers.
>> -
Stian suggested having an SPI for this sort of feature. Either
a
password would be required at Keycloak server startup, or the
password
would be stored in a property file.
Is not the same thing, but do you mean something like Maven does?
(http://maven.apache.org/guides/mini/guide-encryption.html). Maybe a “master password” and
have some sorta of keychain? For example:
1. Master password generates the symmetric key
2. Encrypt the key pairs
3. Decrypt the key pairs on the fly for digital signatures for example.
That’s what do you mean?
>> # 4
>>
>> Generate the keys per session, instead of use it per realm (it
must be tested/implemented because that could slow down our
server)
>>
Not sure this is feasible. In a clustered environment, you'd
need a
trusted way of transmitting all the realm keys. You also would
need a
way to transmit the public key of the realm to each adapter. Each
adapter could make an HTTPS call on bootup to retrieve all relevant
realm metadata, but you'd still have to provide a truststore
for the
adapter so it could make a trusted HTTPS call that verified the
keycloak
server's host. But maybe we need this truststore irregardless
:) ???
But, this still doesn't protect clear text OTP keys (i.e. "What
is your
mother's maiden name?”)
Option 4 must be tested/elaborated better, if you guys think that some of the other
options worth to try, just let me know. Other than that, I will try to help in whatever
you guys think is the best.
5:59 p.m.
On 1/27/2014 11:47 AM, Bruno Oliveira wrote:
Hi Bill, some answers inline. I forgot to add references.
--
abstractj
On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke(a)redhat.com) wrote:
>> More comments inline responding to Bruno's email:
>
>>> # 1
>>> - HSM or Java Security manager are perfect, but impractical
> for regular devs, that would require a lot of maintanance (a dream)
>>>
>
> What is HSM? How could the Java Security Manager protect clear
http://en.wikipedia.org/wiki/Hardware_security_module
> text
> private keys and OTP keys?
With Java Security Manager is possible to restrict code privileges to the resource
specified
(https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Appli...).
For the security manager, this is a compliment to other storage
protection mechanisms and not a replacement, correct?
>
>
>>> # 2
>>> - Entering a password for a PKCS#8/PBKDF2-derived key, also
> impractical assuming that someone would be required to enter
> the password at each app startup
>>>
>>> # 3
>>>
>>> - Not bullet-proof solution, but store the key into a text file
> that only sysadmins and the web server has access, doing our best
> with the usage of ACLs provided by environment. I understand
> Bill's concern
(http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html)
> but at the same time, a file could have a very restricted access
> while the database is more acessible to developers.
>>> -
>
>
> Stian suggested having an SPI for this sort of feature. Either
> a
> password would be required at Keycloak server startup, or the
> password
> would be stored in a property file.
Is not the same thing, but do you mean something like Maven does?
(http://maven.apache.org/guides/mini/guide-encryption.html). Maybe a “master password” and
have some sorta of keychain? For example:
Each realm needs it's own key-pair.
1. Master password generates the symmetric key
2. Encrypt the key pairs
3. Decrypt the key pairs on the fly for digital signatures for example.
That’s what do you mean?
There would be a master password (or key) that is used to encrypt clear
text items in the database. password would be entered from command line
at startup, or grabbed from a secure property file.
I think that's the approach we should take. Unless you can argue for a
better solution?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:03 p.m.
For the security manager, this is a compliment to other storage
protection mechanisms and not a replacement, correct?
Correct
There would be a master password (or key) that is used to encrypt
clear
text items in the database. password would be entered from command
line
at startup, or grabbed from a secure property file.
I think that's the approach we should take. Unless you can argue
for a
better solution?
Not really, this is a tricky problem to solve.
11:12 a.m.
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
(<keycloak>/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);
}
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Monday, 27 January, 2014 4:34:45 PM
Subject: Re: [keycloak-dev] Storage protection
On 1/27/2014 11:30 AM, Anil Saldhana wrote:
> But for development purposes, a DB may not be available as the default
> mechanism. In the case of WildFly AS, I am unsure if they ship with a
> default DB
> anymore.
Wildfly still has a DB, and we use it by default.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:22 p.m.
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?
--
abstractj
On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian(a)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);
}
2:51 p.m.
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(a)abstractj.org>
To: "Bill Burke" <bburke(a)redhat.com>, "Stian Thorgersen"
<stian(a)redhat.com>
Cc: keycloak-dev(a)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...
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(a)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);
> }
3 p.m.
I don't think this relates, but just in case...tokens need to be signed
by a known algorithm so clients are able to verify them.
On 1/30/2014 8:51 AM, Stian Thorgersen 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(a)abstractj.org>
> To: "Bill Burke" <bburke(a)redhat.com>, "Stian Thorgersen"
<stian(a)redhat.com>
> Cc: keycloak-dev(a)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...
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(a)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);
>> }
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:01 p.m.
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(a)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(a)abstractj.org>
> To: "Bill Burke" <bburke(a)redhat.com>, "Stian Thorgersen"
<
stian(a)redhat.com>
> Cc: keycloak-dev(a)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...
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(a)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
5:45 p.m.
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(a)abstractj.org>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)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(a)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(a)abstractj.org>
> > To: "Bill Burke" <bburke(a)redhat.com>, "Stian
Thorgersen" <
> stian(a)redhat.com>
> > Cc: keycloak-dev(a)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...
>
> 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(a)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
5:47 p.m.
I think it does doesn't it?
If using a HSM you'd have to pass the algorithm to use as well so that it can sign it
using the expected algorithm. So it would be:
public byte[] sign(byte[] b, String algorithm);
The interface definitively needs more thinking about ;)
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Bruno Oliveira"
<bruno(a)abstractj.org>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 30 January, 2014 2:00:33 PM
Subject: Re: [keycloak-dev] Storage protection
I don't think this relates, but just in case...tokens need to be signed
by a known algorithm so clients are able to verify them.
On 1/30/2014 8:51 AM, Stian Thorgersen 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(a)abstractj.org>
>> To: "Bill Burke" <bburke(a)redhat.com>, "Stian
Thorgersen"
>> <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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...
>
> 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(a)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);
>>> }
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3738
days inactive
3741
days old
14 comments
4 participants
participants (4)
-
Anil Saldhana -
Bill Burke -
Bruno Oliveira -
Stian Thorgersen