On Fri, 4 Apr 2014 10:49:53 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
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.
Here comes the new
proposal: https://gist.github.com/abstractj/ef1e3d53619796f4e87e
# Passphrase encryption for UPS
**Note**: This is NOT a replacement for SSL
## Scenario
- Developers wants to upload passphrase and certificate for iOS variants. The
passphrase must be stored encrypted and restored in clear while sending
messages.
## Jira references
-
https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout
with Matthias, we agreed that would complicate the developer's workflow.
-
https://issues.jboss.org/browse/AGPUSH-358
## Proposal
Today we can't guarantee that our developers will have an
[
HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage
encryption keys. Neither we can store the private keys in a separated
database, for the push server.
If somehow the database is compromised, private keys could be exposed and
most of the sensitive data decrypted.
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:
```
PK = PBKDF2(Secret Key, Salt)
```
*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
I believe this should be pluggable, not only FS based. For instance, on
AS7/EAP/WF, you'd likely want to use Vault to store sensitive information:
https://access.redhat.com/site/documentation//en-US/JBoss_Enterprise_Appl...
On other containers/platforms, you might have different options. FileSystem is a
good start, but flexibility of such mechanism rocks.
*Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the
server per application and stored into the database.
![](http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg)
### Secret key configuration
The file can be generated and checked if something exists during the
application start up.
- config.properties
```
secret_key =
"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \
"18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ```
or
- config.json
```
{"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532"
\ "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"}
```
### Sending push messages
Passphrases must be reversible for Apple, that's why we make use of symmetric
encryption here.
![](http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg)
# REST API
## Register push app
```POST | rest/applications```
### HTTP request
Remain unchanged
### HTTP response
Remain unchanged
## iOS Variant
### HTTP request
Remain unchanged
### HTTP response
Remain unchanged
## Sender
### HTTP request
Remain unchanged
### HTTP response
Remain unchanged
# Clients
No changes at the client side.
Thoughts?
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev