[aerogear-dev] Security for "Device Registration"

[Matthias Wessendorf]

On Wed, May 22, 2013 at 12:11 AM, Bruno Oliveira <bruno at abstractj.org>wrote:

>
>
> Matthias Wessendorf wrote:
> > Another idea....
>
> I can see a lot of good ideas here, but we have to start to file jiras.
>

Right, but I wanted to "validate" these ideas, instead of creating
countless JIRAs, all being closed "won't fix" / "does not make sense". Main
intention here is really to ask for help, in validating these thoughts



> There will be several several ways to make a system secure.
>
> IMO start simple, make it ultra secure later.
>

yeah, that's my take on it too


>
> >
> > We generate, for EACH variant, an "access-key" with a generated
> > secret(password).
>
> What do you mean about secret? A shared secret? Now we have another
> problem, you must encrypt this shared secret.
>

secret == password


>
> This accessKey:secret combination would be, similar to
> > the previous email, ONLY be able to perform updates for "device
> > (un)registration".
> >
> > It would be NOT possible to use this combination for sending messages to
> > a device, (read: our HTTP send interface would not allow this
> > accessKey:secret combination).
> >
> >
> > Not, sure, but this is (I guess) a bit simpler, initially, instead of
> > using private/public key approach.
> >
>
> I'm still confuse, about what do you want to encrypt and why. Why not
> only create APP-KEY as a point of start, then we figure out how to
> authorize or not a server.
>

Not sure I understand what you mean, but I am not talking about "authorize
an server" (e.g. for sending mails to devices).
These mails are around: devices registers its "application installation" by
submitting "token" to a mobile Variant, ("I am an instance of you,")



>
> Then several people, including me suggesting it will say "it's not
> safe". Then you reply with "fix it" and we can make it work.
>


Not sure what that means? Why would *I* just reply "fix it"? Again, this
was intended for discussion, not "do this, do that".


>
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf <matzew at apache.org
> > <mailto:matzew at apache.org>> wrote:
> >
> >     Hi,
> >
> >     once the app is installed on the phone (or launched in a browser),
> >     we (as discussed in the spec/mailing list) need to upload the
> >     "device token" (or channelID) from the actual device/channel to the
> >     Unified Push Server.
> >
> >
> >     My questions:
> >     Is it safe, if every "Mobile Variant" has a Private/Public Key ???
> >
> >     The UP server keeps the private one.
> >     Once we register a new mobile variant (e.g. HR for Android, HR for
> >     iPad, HR for iPhone, ...) EACH variant has ONE Private/Public key
> >
> >
> >     The Public Key of this combo would be "coded" into the actual mobiel
> >     application...
> >
> >     On EVERY iOS app, it would use the PubKey from the iOS Variant, on
> >     EVERY JS-app, it would use the PubKey from the SimplePush Variant,
> etc
> >
> >
> >     So, that means EVERY installation (on the devices) would have that
> >     pbulci key...
> >
> >     Would that be (extremely) odd, if "1 Mio Russian hacker" would have
> >     that public key, used on the device, to perform some sort of "auth"
> >     (e.g. via HTTP BASIC (just saying.....)) against the server, in
> >     order to upload the "device token" ??
> >
> >
> >     Note: This Private/Public key would/should be EXCLUSIVE for "device
> >     registration". And really ONLY.. :-)
> >
> >     So that this "Private/Public key" pair can NOT be used (==invalid)
> >     for sending messages to the installations, or creating the
> >     Push-Applications / Mobile Variant Constructs.
> >
> >
> >
> >     Greetings,
> >     Matthias
> >
> >     --
> >     Matthias Wessendorf
> >
> >     blog: http://matthiaswessendorf.wordpress.com/
> >     sessions: http://www.slideshare.net/mwessendorf
> >     twitter: http://twitter.com/mwessendorf
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> 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/20130522/464ef0fe/attachment.html