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