On Fri, 4 Apr 2014 10:49:53 -0300 Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning slackland, yesterday I had a hangout with Matthias and we agreed > that the whole key agreement thing would bring more complexity from the > developer’s pespective. That’s the reason why the client with airline was > dropped. > > Here comes the new > proposal: https://gist.github.com/abstractj/ef1e3d53619796f4e87e > > # Passphrase encryption for UPS > > **Note**: This is NOT a replacement for SSL > > ## Scenario > > - Developers wants to upload passphrase and certificate for iOS variants. The > passphrase must be stored encrypted and restored in clear while sending > messages. > > ## Jira references > > - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout > with Matthias, we agreed that would complicate the developer's workflow. > - https://issues.jboss.org/browse/AGPUSH-358 > > ## Proposal > > Today we can't guarantee that our developers will have an > [HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage > encryption keys. Neither we can store the private keys in a separated > database, for the push server. > > If somehow the database is compromised, private keys could be exposed and > most of the sensitive data decrypted.  > > The suggestion is to make use of a *KDF function* per application to encrypt > passphrases, not perfect, but helps (like we did in the past for password > reset). Where encryption key means: > > ``` > PK = PBKDF2(Secret Key, Salt) > ``` > > *Secret Key*: In the ideal world, users would be required to provide a > password for encryption. In this scenario we don't want them to be prompted > to input the password, or add extra parameters to the UPS endpoints. So the > suggestion is to provide secret key configured on the server and protected by > the ACL's from the operating system I believe this should be pluggable, not only FS based. For instance, on AS7/EAP/WF, you'd likely want to use Vault to store sensitive information: https://access.redhat.com/site/documentation//en-US/JBoss_Enterprise_Appl... On other containers/platforms, you might have different options. FileSystem is a good start, but flexibility of such mechanism rocks. > > *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the > server per application and stored into the database. > >  > > ### Secret key configuration > > The file can be generated and checked if something exists during the > application start up. > > - config.properties > > ``` > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ``` > > or > > - config.json > > ``` > {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" > \ "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} >  ``` > > ### Sending push messages > > Passphrases must be reversible for Apple, that's why we make use of symmetric > encryption here. > >  > > # REST API > > > ## Register push app > > ```POST    |    rest/applications``` > > ### HTTP request  > >   Remain unchanged  > > ### HTTP response  > >   Remain unchanged >    > ## iOS Variant  > > ### HTTP request  > >   Remain unchanged  > > ### HTTP response  > >   Remain unchanged > > ## Sender  > > ### HTTP request  > >   Remain unchanged  > > ### HTTP response  > >   Remain unchanged > > > # Clients  > > No changes at the client side. > > > Thoughts? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Quick question: the config.json/property file is something the UPS generates, right ? User has not to build the WAR and put it into the application, right ? On Fri, Apr 4, 2014 at 3:49 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning slackland, yesterday I had a hangout with Matthias and we > agreed that the whole key agreement thing would bring more complexity from > the developer's pespective. That's the reason why the client with airline > was dropped. > > Here comes the new proposal: > https://gist.github.com/abstractj/ef1e3d53619796f4e87e > > # Passphrase encryption for UPS > > **Note**: This is NOT a replacement for SSL > > ## Scenario > > - Developers wants to upload passphrase and certificate for iOS variants. > The passphrase must be stored encrypted and restored in clear while sending > messages. > > ## Jira references > > - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout > with Matthias, we agreed that would complicate the developer's workflow. > - https://issues.jboss.org/browse/AGPUSH-358 > > ## Proposal > > Today we can't guarantee that our developers will have an [HSM]( > http://en.wikipedia.org/wiki/Hardware_security_module) to manage > encryption keys. Neither we can store the private keys in a separated > database, for the push server. > > If somehow the database is compromised, private keys could be exposed and > most of the sensitive data decrypted. > > The suggestion is to make use of a *KDF function* per application to > encrypt passphrases, not perfect, but helps (like we did in the past for > password reset). Where encryption key means: > > ``` > PK = PBKDF2(Secret Key, Salt) > ``` > > *Secret Key*: In the ideal world, users would be required to provide a > password for encryption. In this scenario we don't want them to be prompted > to input the password, or add extra parameters to the UPS endpoints. So the > suggestion is to provide secret key configured on the server and protected > by the ACL's from the operating system > > *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the > server per application and stored into the database. > >  > > ### Secret key configuration > > The file can be generated and checked if something exists during the > application start up. > > - config.properties > > ``` > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" > ``` > > or > > - config.json > > ``` > {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" > \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} > ``` > > ### Sending push messages > > Passphrases must be reversible for Apple, that's why we make use of > symmetric encryption here. > >  > > # REST API > > > ## Register push app > > ```POST | rest/applications``` > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## iOS Variant > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## Sender > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > > # Clients > > No changes at the client side. > > > Thoughts? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

> Oh, the same generated config file could be used for encrypting things for other variants (e.g. the Google API key), at a later time, right ?