<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 3:15 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Good morning, over the weekend I was thinking about how to protect the way how the passphrases are provided in UPS (<a href="https://issues.jboss.org/browse/AGPUSH-358" target="_blank">https://issues.jboss.org/browse/AGPUSH-358</a>) and would like to propose some changes, but before moving forward let's validate if what I am saying makes sense.<br>
<br>
**Note**: Matthias already started some thread about it (<a href="http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-encryption-for-iOS-push-certificate-passphrase-td6174.html" target="_blank">http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-encryption-for-iOS-push-certificate-passphrase-td6174.html</a>). But I didn't get the chance to look UPS and have a decent answer.<br>
<br>
I would like to hear what do you think to start to file Jiras or change the proposal.<br>
<br>
URL: <a href="https://gist.github.com/abstractj/4c6cd242584f4ab406aa" target="_blank">https://gist.github.com/abstractj/4c6cd242584f4ab406aa</a><br>
<br>
# Passphrase protection and friends<br>
<br>
## Current scenario<br>
<br>
- At the moment passphrases and certificates are protected with *HTTPS*, but we also have *CRIME*, *BEAST* and friends.<br>
- From the *UPS* dictionary (<a href="http://aerogear.org/docs/specs/aerogear-server-push/" target="_blank">http://aerogear.org/docs/specs/aerogear-server-push/</a>) I understand a Variant as an application (Android, iPhone....)<br>
- From the usage scenarios, I understand that's possible to send messages to a group of devices. *Ex*: Bruno sends "ahoy" to 3 different variants.<br>
- Currently the passphrase is stored in plaintext<br>
<br>
Reading the sources from *UPS* and the whole documentation I could clearly understand that what do we need might be the same thing being developed for offline, a key management server. I think this must be a separated project to everyone benefit of it.<br>
<br>
## What is the whole idea?<br>
<br>
The idea is kinda of simple, but must be validated to check how it meet your needs, each developer with access on the server side will have her own key pair generated and encoded in binary format. <br>
<br>
![](<a href="http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg" target="_blank">http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg</a>)<br>
<br>
### Some considerations<br>
<br>
- The key pair will be generated in a separated project, not on UPS<br>
- For the key store I'm considering to support the same data stores provided by SPS. What Dan did is a nice a idea (<a href="https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores" target="_blank">https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores</a>)<br>
</blockquote><div><br></div><div>You mean the new "key server" supports multiple databases, right ? <br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- For each key pair will be generated a self signed certificated encoded in DER format and stored into the database (<a href="http://en.wikipedia.org/wiki/X.509" target="_blank">http://en.wikipedia.org/wiki/X.509</a>)<br>
- The key pair will be unique per user, like GPG does. <br>
- We only provide a public key for encryption after successful authentication into the system<br>
<br>
## Changes suggested on UPS server<br>
<br>
1. Login endpoint<br>
<br>
- Current login endpoint:<br>
<br>
POST /rest/auth/login<br>
<br>
- Suggested change:<br>
<br>
I'm not sure if we really need **POST** for login, unless we are changing the state of some resource<br>
<br>
GET /rest/auth/login<br></blockquote><div><br></div><div><br></div><div>Changing from POST to GET (for UPS login) is fine we me. The Login is really only relevant to the Admin UI.</div>
<div>Historically: I picked POST because that's what all of our client libraries use as the default HTTP method for login (JS, iOS and Android)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Response:<br>
<br>
{public-key: <a binary stream or just plain string>}<br>
<br>
2. Register push app<br>
<br>
- Our push clients will need to change to accept the public key provided by the server and encrypt the passphrase. We can make use of *AG Crypto* for it<br>
- The basic workflow for our clients would be:<br></blockquote><div><br></div><div><br></div><div><div>What clients do you mean? The only thing that really does a login against the server is the Admin UI (or a direct curl, using the same 'management' rest-endpoints which are accessed by the AdminUI).</div>
</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Send a login request<br>
- Get the public key<br>
- Encrypt the passphrase<br>
- Send a request like we do at the moment<br>
- For non *AG UPS* clients like *cURL*, the steps with *OpenSSL* will be provided. I also consider the possibility of use GPG as alternative, but something to be tested and evaluated. <br>
<br>
## Future<br>
<br>
- Generate a key pair on the client side to sign our HTTP requests<br>
- Generate the keys per session (<a href="http://en.wikipedia.org/wiki/Ephemeral_key" target="_blank">http://en.wikipedia.org/wiki/Ephemeral_key</a>)<br>
<br>
<br>
<br>
<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></div>