AeroGear Security PicketLink and friends
by Bruno Oliveira
Good morning peeps, currently AGSec PicketLink make use of PicketLink
2.5.0
(https://github.com/aerogear/aerogear-security-picketlink/blob/master/pom....)
and is automagically released under snapshots. I would like to know what
do you prefer:
- AGSec PicketLink release 1.2.2 with PicketLink 2.5.0: could be done in
less than an hour (today)
- AGSec PicketLink release 1.2.2 with PicketLink 2.5.2: I can update
AGSec PicketLink, but must be tested and I don't have too much time now
to update/test/fix our projects like UnifiedPush, AeroDoc, demos on
OpenShift and etc (If someone want to do it, I'm fine)
- Hold it until November and releaseAGSec PicketLink 1.3.0 with
PicketLink 2.5.x: We update AGSec PicketLink with the latest stable
release from PicketLink (Either way I will need help with testing/bug
reports/updating our projects)
Thoughts?
--
abstractj
10 years, 7 months
Security.next - Encrypt all the things and your feedback
by Bruno Oliveira
Aloha kakou and good morning, the time to have fun has come. This week I
was trying to put some ideas for crypto altogether and update our
roadmap for security to reflect what do we want to achieve, basically I
want to hear your opinion on it, otherwise you will implement what was
written here :)
I will wait for some feedback until friday (20) and if I don't hear
anything our roadmap as well AGSEC jiras will be automagically updated.
I don't want to html-ish you, so here comes my proposal formatted in
markdown:
# 1.3.0 (draft)
### Crypto library
* Provide easy to use APIs for symmetric encryption:
[GCM](http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
* Provide easy to use APIs for asymmetric encryption:
[ECC](http://www.nsa.gov/business/programs/elliptic_curve.shtml)
* Provide easy to use APIs for password based key derivation:
[PBKDF2](http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132...
* Provide easy to use APIs for hashing: SHA-256, SHA-512
* Provide easy to use APIs for message authentication: GMAC, HMAC *See:
[AGSEC-57](https://issues.jboss.org/browse/AGSEC-57)*
* Provide easy to use APIs for digital signatures: ECDSA
### Examples:
* Symmetric encryption: SimplePush server
* Asymmetric encryption: shared encryption keys between two parties, to
allow encryption and decryption of messages and prevent tampering.
* Password-based key derivation: every application which requires password
* Hashing: store passwords on the server's database
* Message authentication: message integrity/tampering mitigation
* Digital signatures: HTTP signed requests, digitally sign mobile
application keys (*nonrepudiation*)
**Add more scenarios or exclude but please make sure they are DOABLE and
real**
### Scenarios
* A mobile health system wants to store sensitive patients' data offline
for web or mobile applications
* Bob gets his phone stolen and wants to wipe the data to protect his
privacy
* Alice gets phone stolen and an attacker wants to steal her data
* A web application must be able to provide encryption for users' password
* A TOTP application wants to store shared secrets
* A push mobile application wants to protect the messages exchanged
between client and server
* Showcase **proposed**:
* Password manager
* A password manager app which could be tested with offline sync as a
next step. Initially we can start with the bare minimum
## Jiras
* AGSEC-XX: Provide easy to use cryptography interface
*Description*: We must build a foundation for encrypted storage, before
start hacking on it. Having clearly defined goals in a single place
might help to put things in perspective.
Ex: **Android**-crypto, **iOS**-crypto & **JS**-crypto libraries
* AGSEC-XX: Symmetric encryption support:
[GCM](http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
* AGSEC-XX: Asymmetric encryption support:
[ECC](http://www.nsa.gov/business/programs/elliptic_curve.shtml)
* AGSEC-XX: Password based key derivation:
[PBKDF2](http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132...
* AGSEC-XX: Hashing support: SHA-256, SHA-512
* AGSEC-XX: Message authentication support: GMAC, HMAC *See: AGSEC-57*
* AGSEC-XX: Digital signatures support: ECDSA
*(I'm considering to remove the Jiras below once they are too broad)*
<strike>
* AGSEC-57: Add message integrity verification
* AGIOS-3: Implementation and API usage for iOS crypto
* AGSEC-26: Authentication schemes for mobile devices
</strike>
* AGSEC-2: Secure storage and cache *documentation* (*I'm considering to
make it a doc task. Thoughts?*)
<strike>* AGSEC-7: Provide a detailed specification about how it should
work (*I'm considering to rephrase it*)</strike>
* AGSEC-7: Provide a specification about how to properly do key management
*Description*: Each platform will have its own implementation and
singularity to store/retrieve the keys. For example: *KeyStore* for
Android, *SessionStorage* or *LocalStorage* for JavaScript or *Keychain
services* API with iOS.
* AGSEC-XX: Provide some use case scenarios for encryption: JS, Android, iOS
*Description*: Joint effort from AeroGear team with some scenarios per
platform.
* AGSEC-9: Provide a specification and which kind of algorithms will be
provided
*Description*: Algorithms supported on AeroGear by default. Ex: *GCM,
ECC, GHASH…etc*
* AGSEC-27: Provide a specification and which kind of authentication
schemes will be supported
*Description*: Similar idea to *AGSEC-9* (nothing bureaucratic, just a
short description)
* AGSEC-47: Create a documentation with the overview of AeroGear Security
* AGSEC-XX: Generating encryption keys
* Provide password based encryption support to generate the keys
* Automatically key generation with no interaction
* AGSEC-XX: Manage cryptographic keys and respective owners
*Description*: During the offline encryption a pair of keys (*asymmetric
encryption*) or a single key (*symmetric encryption*) will be generated
to encrypt the local data, we have to figure out what is the best way to
<*put your platform here*> manage those keys.
* AGSEC-XX: Encrypted offline storage (*for sensitive data*)
*Description*: Sensitive data like patients information, social number
security, GPS position or data from your biggest company oil
* AGSEC-XX: Encrypted cache
*Description*: Developers must be allowed to have their application
privacy protected enabling data cache anonymity.
* AGSEC-XX: Key agreement with the server
*Description*: Key agreement between two parties mobile application and
the server
* AGSEC-XX: Key privilege revocation
*Description*: If for some reason a phone get lost or stolen, keys must
be revoked by the server
* AGSEC-XX: Key privilege expiration
*Description*: Allows to specify the valid period of time for the key
added on mobile device or server. Working in both ways.
* AGSEC-XX: Data seek and destroy
*Description*: User/Developer must be able to notify the application
using another authorized computer if the data stored on mobile device
must be destroyed. Ex: *Phone get lost and I want to wipe all the
passwords stored on my device*
* AGSEC-XX: Showcase app
*Description*: An application to showcase the goal of this release.
Suggestion: password manager (*a nice fit for testing encryption locally
and later the integration with the server*)
* AGSEC-XX: Provide a screen to input user's password
* AGSEC-XX: Allow user to include passwords specifying the alias
* AGSEC-XX: Allow password to be decrypted and displayed on the screen
* AGSEC-XX: Backup the data on to the server (*but do not expose the
passwords to the server*)
* AGSEC-XX: Performance checks
*Description*: Check how much encryption will degrade CPU/memory on devices
* AGSEC-XX: Hold the fort
*Description*: Coordinate attacks against our platform. Ex: *DDoS, dump
databases to check if the data was properly encrypted…etc*
*(I'm considering to remove the Jiras below once they are too broad)*
<strike>
* AGSEC-6: Encryption for mobile devices
* AGSEC-89: Encryption for iOS
</strike>
* AGSEC-59: Inclusion of a responsible disclosure for security at
aerogear.org
* AGSEC-58: Setup a mailing list to report security issues
<strike>* AGSEC-61: Http Basic and Http Digest are mutually
exclusive</strike> (*moved*)
--
abstractj
10 years, 7 months
Showcase app idea
by Sebastien Blanc
Hi,
Yesterday evening I was playing Candy Crush Saga[1] on my *iPad*, after
that I logged in into a *secured *area I received some *Push
notifications* about
new levels that were available and even while I was playing I received
notifications from* other users in real time *who connected to the game.
But the battery of my iPad was low so I switched on my *Android* and
because it is still hot here on the French Riviera I went on my balcony but
WIFI was not working really well so I had to play *offline *and I was
really happy because I finally passed that horrible level 99*.*
*
*
After dinner, I went back playing but this time on my destkop computer,
using the *Web Client*, and as soon I got connected the application *
sychronised* itself.
Beside the game content itself which is out of scope, all the things
around : the infrastructure / the game(s) management platform would be
really easy to do with Aerogear (2.0) , it really offers all what is
needed (see the keywords in bold). Maybe that could be something for a
showcase app, a tutorial series or maybe for a GSoC subject.
Would be really fun and sticking to a real use case in a growing sector
(casual mobile games) ...
... Okay going back to Candy Crush
Seb
[1]
http://www.uproxx.com/webculture/2013/07/candy-crush-saga-is-earning-6330...
10 years, 7 months
[simplepush] Batch notifications
by Daniel Bevenius
We have been discussing the possibility of adding batch notifications
support to our SimplePush and UnifiedPush Server. The use case for this
would be when doing a selective send using a category, or a broadcast, and
instead of sending a number of individual HTTP PUT notifications, a single
HTTP PUT notification could be sent.
When sending a notification an endpoint that looks something like this is
used:
https://localhost:7777/update/7linbl5LD9XwCMDfwMeM4vLV8yIwY8Kem32lG2igDng...
The suggestion for sending batch notifications might work by sending a HTTP
PUT but only using:
https://localhost:7777/update
In this case the body of the PUT request must be a valid json in the
following format:
{
"version":"1",
"pushEndpoints":["R32EU3Ct3PuHpEJZbeFQH0JWt_ERUtC4fxox44isNINyWDwatnJ1l1thxQyI1M4-IGvwX3AexkaDiMKpeh3P327MeOm809f9LcCdLw562nOcxxMLmMrhNI4ey4TlQ1mi",
"J_hIZkdLfKZpiwgpQ68QsPPlljnDGBbmPwAwGoe_6mE7ZBaKmebqf1mCDy_c9zII8CyaFC5t9BsGeUSU0nylToQgBKYdV4DFj3zdcpCMnxIHsSpX8Zx9DAjWCv7nfAJz"]
}
The version is pretty much the same as when sending a normal notification
except that it is in json format instead of simply 'version=1'.
The pushEndpoints is an array of channel endpoints. The format of these
could be different for different SimplePush Server implementations so they
are simple strings and the server implementation will know how to interpret
them.
Since batch notifications are outside of the SimplePush specification this
would only work with our implementation and that will complicate things for
the clients, like the UnifiedPush Server for example. It would have to
distinguish between our SImplePush implementation and others.
Another issue that came up while discussing this is the question if this
opens up for denial of service attacks where an attacker could send one
batch notification with a long list of pushEndpoints to try to keep the
server busy. At the moment, for an attacker to do the same thing he/she
would have to send individual request which would be easier to notice and
defend against as there would be a high volume of HTTP traffic.
Thoughts?
10 years, 7 months
Cordova Plugin
by Erik Jan de Wit
Hi,
As you all know cordova is a great way to use the native bits from android or iOS in a HTML5 / javascript application. There are already ideas [1] but we could create a cordova wrapper for all AeroGear functionality. The easiest way to start is use the AeroGear.js api as a start and then on the native side we use the native implementation.
Also to start using unified push with cordova requires quite a lot of setup, we could make that a lot simpler if we incorporate that into our own plugin.
[1] https://issues.jboss.org/browse/AEROGEAR-772
10 years, 7 months
cordova api
by Erik Jan de Wit
Hi,
I was thinking about the cordova api. So ideally I would like to keep it close to the javascript api that we already have, but in cordova all things that are executed have a success and a failure callback so this doesn't really fit.
cordova.exec(successCallback, errorCallback, "AeroGearPlugin", "generateOTP", [secret]);
Nice would be if we could have something like this:
var generator = new AeroGear.Totp(secret);
var totp = generator.generateOTP();
but if we need a callback the closest to something like above will be something like this:
var generator = new AeroGear.Totp(secret);
generator.generateOTP(function(result) { console.log(result) }, function() { console.log('fail') });
maybe it's my not so great javascript knowledge but what do you guys think?
Cheers, Erik Jan
10 years, 7 months
