[aerogear-dev] Passphrase encryption - REST API discussion

Matthias Wessendorf matzew at apache.org
Thu Mar 13 09:01:57 EDT 2014


On Thu, Mar 13, 2014 at 12:59 PM, Bruno Oliveira <bruno at abstractj.org>wrote:

> Good morning slackers, moving forward with my attempt to put pants on
> passphrases. I would like to discuss how the REST API would be with the
> change, because is better to have feedback instead of work for days and
> waste some time.
>
> Register push app:
>
> - HTTP request
>
>   Remain unchanged
>
> - HTTP response
>
> {"id":"2095ab1a-a569-4ae2-a43c-a86b83041592",
> "name":"MyApp",
> "description":"awesome app",
> "pushApplicationID":"ca99487d-6387-41bd-b393-0ce480977efe",
> "masterSecret":"b315d524-e9f9-4d04-946c-b73278ff29be",
> "developer":"admin",
> "androidVariants":[],
> "simplePushVariants":[],
> "chromePackagedAppVariants":[],
>
> "publicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEpsPA31qRWrtiAhnpGBzgwoE435c18gD42y13urb0JSdx4AHQRthhAUFVnu+RqUU8NTp9tGnEEhyBZfbV67arVw==",
> "nonce":"6KbYGZKvTusU+IL3sdY9g=="
> "iosvariants":[]}
>
>
> publicKey: Is the public key created per application and will be optional
> for developers who do care about security. If for some reason they don't
> want to encrypt their passphrase or certificate, that's ok.
>
> nonce: 16 bytes non-deterministic used to encrypt the data on the server
>
> Note: Both would be stored into UPS database (not perfect, but a good
> start)
>

storing both on the server (initially) is fine


>
> Keep in mind that this is just the initial idea, for example, masterSecret
> should never return in clear. To the further interactions it will be fixed
> establishing a key agreement between client and server and encrypt the
> whole response (only for sensitive data). Yeah, I know, we are protected by
> SSL, but we shouldn't trust on it.
>
>
> iOS Variant:
>
> - HTTP request
>
>   Remain unchanged, but now certificate and passphrase can be send
> encrypted and the server will store it.
>


encrptyed w/ the help of the public-key ?




>
> - HTTP response
>
>   Remain unchaged
>
> Sender:
>
> - HTTP request
>
>   Remain unchanged,



w/ "unchanged" you basically mean the payload of the "Send request" is the
same as it is today, right ?



> but now the server will search for the application ID and retrieve the
> public key to decrypt application's passphrase
>


Ok, that's internal details. So the server basically deprcypts both: cert
and its passphrase, in order to establish the connection to APNs




>
> - HTTP response
>
>   Remain unchanged
>
>
> AeroGear Clients
>
> - cURL
>
> Yesterday I had the amusing experience of dig into the sources of OpenSSL
> and their documentation, to see how people could encrypt it from the
> command line. If I recommend that people would remember my name for the
> eternity in a bad way. Another insane idea was to provide encoders for GPG.
> The simplest idea, I think, would be provide code for people encrypt their
> passphrase and certificate, instead of trust in some software.
>

but that's really just for the "registration part", right ? I don't care
that much about a cumbersome API there :-) Because in 99% of all cases the
actual registration (and cert/passphrase upload) is done via the sexy Admin
UI.


The CURL for the send stays the same as it is today, right ?



>
> - aerogear-unifiedpush-java-client
>
> No problem to implement it.
>
> - aerogear-simplepush-java-client
>
> No problem to implement it.
>
> - aerogear-simplepush-node-client
>
> Not so easy, but they do OpenSSL behind the scenes
>
> - aerogear-unifiedpush-nodejs-client
>
> Not so easy, but they do OpenSSL behind the scenes
>
>
> So, what do you think? Yay/Nay? I would never use that?
>
> The goal is to provide secure alternatives to developers, but if the whole
> process will turn into a pain, I won't move forward.
>


It looks like it goes towards the right direction!

Thanks for looking into it




>
>
>
>
>
> --
> 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/20140313/ff864f03/attachment.html 


More information about the aerogear-dev mailing list