[aerogear-dev] Passphrase protection proposal and UPS

[Matthias Wessendorf]

On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, over the weekend I was thinking about how to protect the way
> how the passphrases are provided in UPS (
> https://issues.jboss.org/browse/AGPUSH-358) and would like to propose
> some changes, but before moving forward let's validate if what I am saying
> makes sense.
>
> **Note**: Matthias already started some thread about it (
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-encryption-for-iOS-push-certificate-passphrase-td6174.html).
> But I didn't get the chance to look UPS and have a decent answer.
>
> I would like to hear what do you think to start to file Jiras or change
> the proposal.
>
> URL: https://gist.github.com/abstractj/4c6cd242584f4ab406aa
>
> # Passphrase protection and friends
>
> ## Current scenario
>
> - At the moment passphrases and certificates are protected with *HTTPS*,
> but we also have *CRIME*, *BEAST* and friends.
> - From the *UPS* dictionary (
> http://aerogear.org/docs/specs/aerogear-server-push/) I understand a
> Variant as an application (Android, iPhone....)
> - 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.
> - Currently the passphrase is stored in plaintext
>
> 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.
>
> ## What is the whole idea?
>
> 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.
>
> ![](
> http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg)
>
> ### Some considerations
>
> - The key pair will be generated in a separated project, not on UPS
> - For the key store I'm considering to support the same data stores
> provided by SPS. What Dan did is a nice a idea (
> https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores
> )
>

You mean the new "key server" supports multiple databases, right ?




> - For each key pair will be generated a self signed certificated encoded
> in DER format and stored into the database (
> http://en.wikipedia.org/wiki/X.509)
> - The key pair will be unique per user, like GPG does.
> - We only provide a public key for encryption after successful
> authentication into the system
>
> ## Changes suggested on UPS server
>
> 1. Login endpoint
>
>         - Current login endpoint:
>
>                 POST            /rest/auth/login
>
>         - Suggested change:
>
>                 I'm not sure if we really need **POST** for login, unless
> we are changing the state of some resource
>
>                         GET                     /rest/auth/login
>


Changing from POST to GET (for UPS login) is fine we me. The Login is
really only relevant to the Admin UI.
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)



>                 Response:
>
>                         {public-key: <a binary stream or just plain
> string>}
>
> 2. Register push app
>
>         - 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
>         - The basic workflow for our clients would be:
>


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).




>                 - Send a login request
>                 - Get the public key
>                 - Encrypt the passphrase
>                 - Send a request like we do at the moment
>         - 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.
>
> ## Future
>
> - Generate a key pair on the client side to sign our HTTP requests
> - Generate the keys per session (
> http://en.wikipedia.org/wiki/Ephemeral_key)
>
>
>
>
>
> --
> abstractj
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev




-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/b1d17137/attachment-0001.html