[aerogear-dev] Passphrase encryption - round III

[Karel Piwko]

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