[aerogear-dev] Passphrase encryption - round III

[Bruno Oliveira]

Cool, I'll look at this—
abstractj

On Fri, Apr 4, 2014 at 12:07 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Fri, 4 Apr 2014 10:49:53 -0300
> Bruno Oliveira <bruno at abstractj.org> 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_Application_Platform/6.2/html/Security_Guide/sect-Password_Vaults_for_Sensitive_Strings.html
> 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.
>> 
>> ![](http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg)
>> 
>> ### 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.
>> 
>> ![](http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg)
>> 
>> # 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/cd7ac418/attachment.html