<div dir="ltr">+1 <div><br></div><div>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 ? </div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Apr 4, 2014 at 3:49 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Here comes the new proposal: <a href="https://gist.github.com/abstractj/ef1e3d53619796f4e87e" target="_blank">https://gist.github.com/abstractj/ef1e3d53619796f4e87e</a><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 passphrase must be stored encrypted and restored in clear while sending messages.<br>
<br>
## Jira references<br>
<br>
- <a href="https://issues.jboss.org/browse/AGPUSH-565" target="_blank">https://issues.jboss.org/browse/AGPUSH-565</a> (*Dropped*). After a hangout with Matthias, we agreed that would complicate the developer's workflow.<br>
- <a href="https://issues.jboss.org/browse/AGPUSH-358" target="_blank">https://issues.jboss.org/browse/AGPUSH-358</a><br>
<br>
## Proposal<br>
<br>
Today we can't guarantee that our developers will have an [HSM](<a href="http://en.wikipedia.org/wiki/Hardware_security_module" target="_blank">http://en.wikipedia.org/wiki/Hardware_security_module</a>) to manage encryption keys. Neither we can store the private keys in a separated database, for the push server.<br>
<br>
If somehow the database is compromised, private keys could be exposed and most of the sensitive data decrypted. <br>
<br>
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:<br>
<br>
```<br>
PK = PBKDF2(Secret Key, Salt)<br>
```<br>
<br>
*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<br>
<br>
*Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the server per application and stored into the database.<br>
<br>
![](<a href="http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg" target="_blank">http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg</a>)<br>
<br>
### Secret key configuration<br>
<br>
The file can be generated and checked if something exists during the application start up.<br>
<br>
- config.properties<br>
<br>
```<br>
secret_key = "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \<br>
"18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"<br>
```<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 encryption here.<br>
<br>
![](<a href="http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg" target="_blank">http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg</a>)<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>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>