Encryption intents

[Peli]

There has been a post in our forum by Isaac suggesting a set of
encryption intents:
http://www.openintents.org/en/node/150

"...the functionality for prompting for a password, storing the
password, changing the password, encrypting, and decrypting data might
make a good standalone intent so that you don't have to bake that all
explicitly into every application. "

This looks very promising, as it may allow to encrypt data in various
applications.

Following questions come to my mind:
* Should there be one master password for all applications? Or rather
let each application have their own password (which the user can set
to be the same if they like)

* To make it a useful standalone application by itself, "OI
Crypto" (if I may call it that way :-) ) could be an application for
storing a list of encrypted passwords for other applications, web
sites, email accounts, etc..

Which intents would we need?
* Intent to prompt for a password
* Intent to encrypt and decrypt data, where data can be provided as
extra and returned as extra (would this be safe? or could an intent-in-
the-middle attack catch the decrypted message?)

* Alternatively: How involved are the routines for encrypting /
decrypting? If that is not too much overhead, they could be compiled
into each apk (e.g. through a small jar library). Or is this even more
of a security risk?

Using only intents, one could design the system probably in such a
way, that no other apk (except for OI Crypto) ever gets to see the
password.

I think it is a very cool idea :-)

Peli

[Al Sutton]

Peli,

Encryption is pretty trivial, the code to decrypt some data using RSA
for a specific key is;

X509EncodedKeySpec keySpec = new X509EncodedKeySpec(DECODING_KEY);
KeyFactory factory = KeyFactory.getInstance("RSA");
PublicKey key = factory.generatePublic(keySpec);
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] original = cipher.doFinal(ENCRYPTED_DATA);

So I'm not sure how useful a central encrypter/decrypter would be.

What could be useful is a single sign on solution whereby users sign in
to an OI SSO app and the OI SSO app can then provide passwords to named
resources for other apps.

Al.

--
======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

[Peli]

Hi Al,

You're probably right that it introduces a lot of overhead. I still
see two advantages if a central encrypter is being used:

- as you mentioned, SSO: User signs in once, and can access all their
encrypted data in various applications, until they either globally
sign out or there is another condition (time-out, power-save-mode,..).

- Store your password in a single place: You don't want to trust all
apps that you download from somewhere, especially if it has internet
permission. Either one has to invent a new password for each new app,
or you store it in a central place that is also responsible for
encrypting / decrypting messages, so the central crypto app *never*
gives away the password or hands it to the various applications.
Needless to say, there is no need for the central crypto app to have
the internet permission or any other permissions (except for accessing
the db file with the password).

Maybe it is all easier to set together than I thought at the
beginning :-)

Thanks for your code snippet :-)

Peli

[qvark]

Hi,

we at BioWallet have been working on similar intents the last few
months, so we would like to share our point of view and get involved
in the intents definition.

First, we think defining a set of standard intents that provide
security services and can be used by third party applications is
important. We have discussed this issue with some members of the
Android team in the past to see them added in the "standard" list of
intents (http://code.google.com/android/reference/available-
intents.html) and they agreed it was an interesting idea but no for
1.0.

The idea is third party applications could use these intents without
worrying about the implementation, and the user could choose
BioWallet, Open Intents implementation or whatever to provide these
security services.

The intents we currently support are:

com.biowallet.ENCRYPT - Encrypt a document

com.biowallet.DECRYPT - Decrypt a document

com.biowallet.SIGN - Digitally sign a document -

com.biowallet.VERIFY_SIGNATURE - Verify digital signature of a signed
document

com.biowallet.AUTHENTICATE - Authenticate user

com.biowallet.CHECK_AUTHENTICATED - Check if the user is already
authenticated

We also have modified the Google Notepad example to use these intents
and become a "Secure Notepad" with very little effort.

We would like to hear your opinion because we really want to implement
a standard set of intents that are useful for other applications.

We can provide more details if you find them interesting.

Best regards,

Jose Luis Huertas
BioWallet Team
www.biowallet.net

[Isaac]

Hi gang,

I agree that an encryption intent isn't too difficult. I modified OI
Notepad more or less as a learning experience, but I think that there
are some standard behaviors that a set of well defined intents could
usefully provide.

(By the way, I got the encryption and UI code from Passwordsafe so
that's at least two programs that could use it ;)
http://code.google.com/p/android-passwordsafe/ )

= A simple encrypt/decrypt intent =

* The user should be able to type in their password just once for
multiple applications. We could avoid allowing various applications to
actually have access to the password, (just the ability to encrypt &
decrypt) which is nice.

* Store certain preferences from the user:
* How long to remember the password they've typed in
* change the password
* Maybe we could plug into the "draw a pattern on the screen"
capability instead of using a password

* Query for and store the password. This involves generating an MD5
of the password and storing that MD5 in the database so that when the
user enters in the password you can detect whether it's correct.
Otherwise it's hard to tell if you're properly decrypting things,
although maybe there's a better way. That's how passwordsafe did it.

* Changing the password is tricky with the method used here; if you
wanted to change the AES password, you'd have to go through and re-
encrypt everything, so some kind of indirection would be necessary,
possibly with a private key, gnupg style? Not sure what the best way
to do that is.

* Really I should look at how Gnome already does stuff like this so
as to not reinvent the wheel :)


= A more complex system =
* Store public & private keys, and provide the kinds of functionality
that Jose suggested. I like that idea, but maybe it would be good to
get a simple version like above working first :)
* Perhaps we could provide a crypto ContentProvider so it would be
really easy to use?

I dropped the code up onto the web as a darcs repository, or you can
just scp it to play with it. The darcs repo maintains the original
code so you can see everything as diffs if you want:

darcs get http://www.syntaxpolice.org/tmp/CryptoNotePad

peace,

isaac

p.s. It's a shame to see that the biowallet folks aren't able to
release their product because they don't have access to a G1 phone!

[Al Sutton]

I can see the benefit of the intent, but I think we need to scope out
things like whether or not the encryption/signing algorithm name should
be a parameter, and how to handle data streams (i.e. reading a large
file and decrypting only the parts the app needs to read).

Al.

P.S. To get around the password change problem you can have a single AES
key which decrypts all of the other keys which are held in the store.
When the user changes their password you just need to re-encrypt the
master key with the new password.

[Peli]

Hi Jose,

This sound great! The most important part is that the protocol is very
clear and there is at least one open source implementation. This
ensures that other security services can be fully compatible.

The ideal scenario could be something like this:
User starts for example with the OI Crypt, assigns a password,
encrypts all their notes in OI notepad and shopping lists in OI
shopping list.
Later they find they want the additional capabilities from Bio Wallet,
so they switch to BioWallet. They just have to enter the master key
there, and can use Bio Wallet to handle all encryption, and deinstall
OI Crypt, seemlessly (no need to decrypt and encrypt all notes and
shopping lists!). Or they can have both installed and switch between
those applications.

Hm, this requires some thinking:
First of all, AUTHENTICATE (which I assume is the activity that
prompts the user for a password) should probably return the package
name in the extras. So the user can choose at authentication time
which security provider they want to use (through an ACTIVITY PICKER),
and all subsequent intents (ENCRYPT, DECRYPT, SIGN, ...) could then be
addressed to that specific package directly (instead of prompting the
user every time something needs to be encrypted / decrypted).

I guess one intent missing on your list is SIGN_OUT (if I assume that
one stays signed in for a certain period in time?)

If you want, I can offer you to host the intents in the OpenIntents
name space (org.openintents.action.AUTHENTICATE, ...), and we could
provide an open source implementation. This could raise the acceptance
level, and would be just half a step away from having them in the
Android namespace itself :-)

The encryption algorithm details should be part of the extras, and the
main goal should be that encryption could be easily implemented in 3rd
party apps that want to use these features.

Let me know what you think.

Peli

[Peli]

Hi Isaac,

I see there are plenty of ideas :-) Yes, we should probably tackle
this from bottom up - have a simple system implemented that can then
be enhanced step-by-step.

One of the first basic questions would be though, whether we wanted to
have the possibility to change the password - so that there could be
one Master password (which is used to encrypt/decrypt all data), and a
user password (which is used to encrypt the Master password), as Al
mentioned. So the user can change the user password, without changing
the Master password. (master password could be long and secure, while
the user password may be shorter and easier to type on the phone).

The user should still know the Master password, or it would be
impossible for them to switch to another security service provider.
(I guess this is an important aspect also in BioWallet's
implementation).

A true changing of the master password would require considerably more
effort:
The central security service should have to ask all installed
applications to send in all their encrypted data, it would them
decrypt them and encrypt them with the new key and send them back.
But all installed apps would have to support this functionality in
order to work.

Ok, so the easiest implementation would be to start with a single
Master password that is assumed to never changed.

The rest (simpler user password that can be changed) could be
implemented later on top of that.

Now it is all a question of defining the intents and extras...

Peli

On 24 Nov., 01:02, Isaac <isaac.jo...@gmail.com> wrote:
> Hi gang,
>
> I agree that an encryption intent isn't too difficult. I modified OI
> Notepad more or less as a learning experience, but I think that there
> are some standard behaviors that a set of well defined intents could
> usefully provide.
>
> (By the way, I got the encryption and UI code from Passwordsafe so

> that's at least two programs that could use it ;)http://code.google.com/p/android-passwordsafe/ )

>  darcs gethttp://www.syntaxpolice.org/tmp/CryptoNotePad

[Peli]

By the way, it has been suggested that we should be compatible with
the open source KeePass:
http://keepass.info/
http://keepassserver.info/ (J2ME version)

Peli

[Peli]

I have one more question regarding the implementation of an intent:

* activity intents, or
* broadcast intents

Activity intent is nice, because you can receive a result
(startIntentForResult() / onActivityResult() ). The drawback is that
there is quite a bit of overhead involved, even if one calls finish()
right in onCreate() (hm, is that actually the case? does the calling
activity have to go through the onPause() / onResume() cycle?)

Broadcast intent seems to be more lightweight, but the calling
activity has to implement a broadcast receiver in order to receive
results sent back again through another broadcast intent. (these could
be addressed to the sending package directly).

I guess implementing a service with AIDL would be the fastest way for
repeated requests, but too involved...

I'm thinking of the use case in a list activity that displays a list
of encrypted items, and the DECRYPT intent has to be called for each
of the items...

What would be the best way to implement this using intents if one
wants small overhead + easy implementation?

Peli

[Isaac]

Hi gang,

I've been thinking a bit and hacking a bit... It seems like the
passwordsafe program would make a fine keyring application as a basis
for the crypto intent. It could be used for easy encryption using the
"master" key, or as an API for applications to store & retrieve
passwords, locked by the "master" key (similar to how gnome stores
wireless network keys).

To get started, I modified the passwordsafe application to use some
indirection, as mentioned previously.

When the user logs in, I generate a DES key. The user also gives a
password for a PBE key. I encrypt the DES key wit the PBE key and
store the encrypted DES key and an encrypted MD5 of the decrypted DES
key in the database.

The next time the user logs in, I decrypt both and check the MD5 to
make sure that their pbe key is correct before letting them in
further.

All the passwords are encrypted with the DES key, not the PBE Key.
This way, someone can change the PBE Key and only have to re-encrypt
the DES key, as we've discussed.

Does this sound like an OK way to go? Here's the code if you want to
look:

http://www.syntaxpolice.org/tmp/android-passwordsafe-darcs/

I'm thinking I'll have some hacking time this week, so I'll look into
making this into an encrption intent as discussed. I also gave the
passwordsafe author (and fellow portlander) Steven Osborn.

peace,

isaac

[Isaac]

Hi Peli,

I think that it makes sense to generate a strong "master" password
that's independent of the "user" password. The user password could be
something from biowallet, or a regular password, or a little pattern
that the user draws on the screen.

Let's say that the user uses a keyboard-entered password, and then
later they want to use biowallet. The biowallet application would get
installed, realize that there's already an encryption intent provider
installed (say, an openintents one), and ask permission to get the
decrypted strong master password (which the user would unlock using
their key).

Then biowallet could re-encrypt the master password however they want
and thereafter be able to decrypt and encrypt everything based on the
master password.

If we take an incremental approach to building this out, we'll have to
be most craeful about how we do this master password, since it'll be a
difficult aspect to change as soon as there is encrypted data out in
the wild.

Of course if biowallet has already done this, maybe they are going to
opensource their stuff, or they already have? :)

peace,

isaac

[Peli]

Hi Isaac,

Looks great! I just wonder whether it would not be better (or at least
an option) to let the user choose a master password instead of
generating it? (the software should demand to make that a strong
password - through a longer minimum length, combine small / capital
letters / numbers / special characters, ...)

This way they could store it somewhere else safely, so when the phone
gets lost the user could still access the backup notes on their
computer at home.

Your mechanism of passing the Master password between applications
still seems very user friendly.

Peli

[Jose Luis Huertas Fernández]

Hi guys, I'm sorry for not answering before, but I have been quite busy this week.

I like the idea of encrypting everything with a strong "master" password that is independent of the mechanism the user uses to authenticate himself (another password, biometrics, digital certificate, ...) As you have already said, the authentication mechanism unlocks the master password, and then that key is used to encrypt/decrypt the data. 

Also, I don't think letting the user know about that password is useful. Why the user should worry about it? why take the risk of a non-expert user choosing a weak password or writing it down in a piece of paper? why limit it to "writable" characters? I think it is better this password is just a sequence of fully random bits (they don't even have to be valid characters) generated with the maximum length we choose (256 bits would be OK).

BTW, this is the way BioWallet works right now, so I think we could contribute some pieces of code, but unfortunately we cannot help too much because we are quite busy with our own problems (biometrics, lack of memory and performance problems in the Android platform) ;)

Cheers,

Jose Luis.

[Al Sutton]

Couple of quick question Isaac;

1) Any reason you're using MD5/DES instead of SHA1/AES which are more
recent and considered more secure?

2) Any reason you need to check against the hash (MD5) of the DES key?,
I would have thought a check against a hash of the users password would
have been enough to verify the validity of the users password.

Al.

[Isaac]

On Nov 30, 2:44 am, Al Sutton <a...@funkyandroid.com> wrote:
> Couple of quick question Isaac;
>
> 1) Any reason you're using MD5/DES instead of SHA1/AES which are more
> recent and considered more secure?

Not really any reason for this. I can switch it.

> 2) Any reason you need to check against the hash (MD5) of the DES key?,
> I would have thought a check against a hash of the users password would
> have been enough to verify the validity of the users password.

Hm. That will tell us if the password is right, but checking the hash
of the DES key tells us that both the key and the password are right.
Do you see a problem with storing the hash of the DES key?
Theoretically if the password is right then there shouldn't be a
problem, but it seems a bit nicer to be sure that the key you're using
to encrypt everything has come out of the database clean.

peace,

isaac

[Al Sutton]

With 2 the thing to remember is that the more ways you have of verifying
a key is correct, the more hints a crypto-hacker has as to what the
original key might be.

Al.

[Peli]

Hi Jose,

Do you have some specifics of the intents you mentioned above that you
can share with us? Would those intents be part of a public API that
you would like to share?

Peli

On 30 Nov., 10:56, "Jose Luis Huertas Fernández"

<joseluishuertasfernan...@gmail.com> wrote:
> Hi guys, I'm sorry for not answering before, but I have been quite busy this
> week.
> I like the idea of encrypting everything with a strong "master" password
> that is independent of the mechanism the user uses to authenticate himself
> (another password, biometrics, digital certificate, ...) As you have already
> said, the authentication mechanism unlocks the master password, and then
> that key is used to encrypt/decrypt the data.
>
> Also, I don't think letting the user know about that password is useful. Why
> the user should worry about it? why take the risk of a non-expert user
> choosing a weak password or writing it down in a piece of paper? why limit
> it to "writable" characters? I think it is better this password is just a
> sequence of fully random bits (they don't even have to be valid characters)
> generated with the maximum length we choose (256 bits would be OK).
>
> BTW, this is the way BioWallet works right now, so I think we could
> contribute some pieces of code, but unfortunately we cannot help too much
> because we are quite busy with our own problems (biometrics, lack of memory
> and performance problems in the Android platform) ;)
>
> Cheers,
>
> Jose Luis.
>

[Jose Luis Huertas Fernández]

Hi Peli, I'm writing a document summarizing what as been already said an adding some details about the intents. I will try to finish it by tomorrow morning (CET) ;)

Cheers,

Jose Luis.

[Peli]

The passwordsafe application looks like a good starting point. We
should collaborate on the necessary intents :-) Then we could have
four applications that work together through the intents system:
Passwordsafe, Biowallet, Notepad, Shopping list :-)

Peli

On 30 Nov., 00:55, Isaac <isaac.jo...@gmail.com> wrote:

[Peli]

Here is the link to the discussion in the Passwordsafe group:
http://groups.google.com/group/android-pws/browse_frm/thread/48a8a983b8b9ade6#
http://code.google.com/p/android-passwordsafe/

Peli