opensc-devel

[Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Anders R. <and...@gm...>]

http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html

Unlike the situation for discrete smart card there's no middeware to install; it is provided by the OS vendor.

Unless the smart card industry manage getting the same support they will sooner or later face severe adoption issues except in isolated government markets like e-passports.
This obivoisly calls for a completely standard PKI card...

Anders

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Andreas J. <an...@io...>]

2013/8/27 Anders Rundgren <and...@gm...>

>
> http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html
>
> Unlike the situation for discrete smart card there's no middeware to
> install; it is provided by the OS vendor.
>
> Unless the smart card industry manage getting the same support they will
> sooner or later face severe adoption issues except in isolated government
> markets like e-passports.
> This obivoisly calls for a completely standard PKI card...
>

Wow, you are still a huge believer in the smart card industry. Is there a
good reason for that?

Smart cards are incompatible !"/%"!"! and they don't work well anywhere,
other in protected environments like closed systems - national eid cards,
banking cards, access control cards etc.

I can even understand well why that is: managing a single use card is so
much easier than cooperating on a multi use card, with all the management
nightmare as a fall out.

Thus I believe there is no reason to hope the smart card situation will
change, as there is no benefit for any player to change its behaviour.

Still thank you for sharing that article. I find it very interesting to see
how the security system moves into the HSM like direction with no
integrated storage. I worked with ibm HSM systems, and there you too only
have the master encryption key inside the HSM, and all other credentials
are stored in encrypted form on the host, and handed in to the HSM on
demand for performing some operation.

Sure, a smart card can do more, and for having a card that is powered only
when in a reader / next to the reader, an integrated system of storage and
crypto functions is nicer. But for security in the device environment: why
isn't the HSM like mechanism superior? it seems easier to implement to me,
and is far more flexible - no fuzzing around with PKCS#15 structures,
storing the credentials on the host is far easier.

Regards, Andreas

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[NdK <ndk...@gm...>]

Il 28/08/2013 08:09, Andreas Jellinghaus ha scritto:

> Sure, a smart card can do more, and for having a card that is powered
> only when in a reader / next to the reader, an integrated system of
> storage and crypto functions is nicer. But for security in the device
> environment: why isn't the HSM like mechanism superior? it seems easier
> to implement to me, and is far more flexible - no fuzzing around with
> PKCS#15 structures, storing the credentials on the host is far easier.
I agree with your vision to a great extent.
But it's a partial vision (not all systems are constantly on-line).

A smartcard is something you can bring around easily. You can't do the
same w/ an HSM.
Sure, it lacks some features (like a pinpad and a display), but that
depends on the chosen security perimeter and ability to work offline.
But extending the security perimeter makes it harder to defend.

Probably (quite for sure...) nowadays the smartcard form factor is
"wrong": microsd or USB token have many advantages (first of all:
communication speed!) that could open many scenarios...

BYtE,
 Diego.

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Jean-Michel P. - G. <jm...@go...>]

Le mardi 27 août 2013 à 08:13 +0200, Anders Rundgren a écrit :
> http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html

Very interesting article, thank you.  

Let's focus on the article, before drawing any conclusion.

Quoting the article:
****
An interesting detail is that, the QSEE keystore trusted app (which may
not be a dedicated app, but part of more general purpose trusted
application) doesn't return simple references to protected keys, but
instead uses proprietary encrypted key blobs (not unlike nCipher Thales
HSMs). In this model, the only thing that is actually protected by
hardware is some form of 'master' key-encryption key (KEK), and
user-generated keys are only indirectly protected by being encrypted
with the KEK.

[...]

To sum this up, while TrustZone secure applications might provide
effective protection against Android malware running on the device,
given physical access, they, as well as the TrustZone kernel, are
exploitable themselves. 
***

Here is what Android 4.3 does :

* Only master key is backed-up in QSEE keystore hardware (when crypto
chip available). Otherwize, master key is backed-up in software (when no
crypto chip is available). Therefore only a tiny portion of 4.3 Android
systems are secure.

* QSEE Slave keys are encrypted using master key. There are no real
details given on master key and we don't know to which extent it is safe
(crypto chip security level not described in article). 

* TrustZone secure applications are encrypted using QSEE slave keys
(sounds reasonable to believe so).

* Therefore if master key is compromised, QSEE Slave keys and TrustZone
secure applications may be compromised.

* If kernel is compromised, it may be possible to bypass QSEE and
TrustZone.

Please correct me if I am wrong.

Kind regards,
-- 
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Anders R. <and...@gm...>]

Hi JM,
I think your conclusions regarding security are correct.
I.e. this is not a perfect solution.

Why do I still believe is it significant?
Because it offers [improved] security for the mass-market.

Storing the KEK inside of the CPU with a built-in security processor is
a logical next step.  I.e. the security processor would for example
have a method like RSASign (EncryptedKeyBlob).  I have built this
in software and it was close to trivial.  Here is PDF describing it:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/tee-se-combo.pdf

Cheers
Anders

On 2013-08-28 18:55, Jean-Michel Pouré - GOOZE wrote:
> Le mardi 27 août 2013 à 08:13 +0200, Anders Rundgren a écrit :
>> http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html
> 
> Very interesting article, thank you.  
> 
> Let's focus on the article, before drawing any conclusion.
> 
> Quoting the article:
> ****
> An interesting detail is that, the QSEE keystore trusted app (which may
> not be a dedicated app, but part of more general purpose trusted
> application) doesn't return simple references to protected keys, but
> instead uses proprietary encrypted key blobs (not unlike nCipher Thales
> HSMs). In this model, the only thing that is actually protected by
> hardware is some form of 'master' key-encryption key (KEK), and
> user-generated keys are only indirectly protected by being encrypted
> with the KEK.
> 
> [...]
> 
> To sum this up, while TrustZone secure applications might provide
> effective protection against Android malware running on the device,
> given physical access, they, as well as the TrustZone kernel, are
> exploitable themselves. 
> ***
> 
> Here is what Android 4.3 does :
> 
> * Only master key is backed-up in QSEE keystore hardware (when crypto
> chip available). Otherwize, master key is backed-up in software (when no
> crypto chip is available). Therefore only a tiny portion of 4.3 Android
> systems are secure.
> 
> * QSEE Slave keys are encrypted using master key. There are no real
> details given on master key and we don't know to which extent it is safe
> (crypto chip security level not described in article). 
> 
> * TrustZone secure applications are encrypted using QSEE slave keys
> (sounds reasonable to believe so).
> 
> * Therefore if master key is compromised, QSEE Slave keys and TrustZone
> secure applications may be compromised.
> 
> * If kernel is compromised, it may be possible to bypass QSEE and
> TrustZone.
> 
> Please correct me if I am wrong.
> 
> Kind regards,
> 
> 
> 
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Jean-Michel P. - G. <jm...@go...>]

Le jeudi 29 août 2013 à 06:00 +0200, Anders Rundgren a écrit :
> I think your conclusions regarding security are correct.
> I.e. this is not a perfect solution. 

My next step was to test Android 4.3 in real life, which I did during
the night, as I was too busy to play.

I used a Nexus7 hardware with embedded crypto chip. The very same
hardware which is described in the article.

First of all, Android 4.3 has a strange option to become what is called
"Administrator". When such option is triggered, you can connect on your
Gmail account and disable your tablet remotely and reformat flash card.

This indicated that under some conditions, Gmail and Google can be the
administrator of your tablet and have total control remotely.

This is the first time ever that I test such a feature on a computer.

In movie Elysium:
http://fr.wikipedia.org/wiki/Elysium

Kruger (Sharlto Copley) certificates and authorizations are canceled
remotely by Jessica Delacourt (Jodie Foster) interactively. In the
movie, Kruger IS a war criminal, so this is normal. There are also very
good shots about a Faraday cage, but this is not the issue here. 

Here, the issue is certificate management over the Internet.

There is some kind of such mechanism in Nexus7, as it seems that all
certificates can be canceled remotely using GMail. The scope of control
is unknown: user only, Google itself, US government, or local government
(France government for France, German government for Germany, etc ...).
Sincerely, I have no idea. This seems normal for French government to
disable a tablet of a French citizen in case of extreme emergency and
this is not shocking IMHO. But other scopes are unknown.

Under Nexus7, there is also this strange option for voice recognition,
where the tablet can listen to conversations with or without Internet
connection and display the text. I could test with very unusual
sentences and it worked like a charm. The only error is that the tablet
mixed "dog" with "cat", but it was clearly Okay.

What does "Voice recognition" with Internet connection means? Simple:
your voice is processed remotely in the cloud with power of thousands of
CPUs. We know what it means.

Together, the impact of:
* embedded cryptography using unknown chips, 
* total control over certificates (probably through master key or some
slave keys) using Internet, 
* total control over reboot and reformat of tablet,
* AND voice recognition (in French we say this is "la cerise sur la
gateau"),
AND security leaks built in the system (i.e. leading to well-known
exploits and backdoors)

IS unknown.

This is the least to say!

For sure, Android 4.3 and Nexus7 are not usable in any kind of Company,
University or and mainly not any kind of Government or any kind of
Administration, local or central or any kind of association or charity.

I am quite surprised, actually, did Google register the cryto chip at
ANSSI (French administration for crypto), as it is requested?

My Nexus7 tablet is now shut-down and I will probably not start it
again, even to make screenshots. I am waiting for an upgrade of the
Android system, which would allow businesses to use the tablet in decent
conditions.

Thank you again for this interesting article, which convinced me to
avoid any management of certificates over Internet. So the future
belongs to smartcards and USB tokens. We draw a different conclusion as
yours. And this is still needed to register cryto-chips at ANSSI,
France, for security and also freedom.

Kind regards,
-- 
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Anders R. <and...@gm...>]

On 2013-08-29 14:58, Jean-Michel Pouré - GOOZE wrote:
<snip>
> 
> Thank you again for this interesting article, which convinced me to
> avoid any management of certificates over Internet. 

JM, actual *usage* of certificates issued over the Internet in the
EU already exceed that of smart cards for the reasons I have mentioned
over and over: the lack of usable standards that doesn't require
end-users to hang out in OpenSC list...

> So the future belongs to smartcards and USB tokens.

For e-passports and governments, yes.  For the private sector
including banks the future looks awfully grim unless Feitian
and other vendors begin to take the threat from Google a bit
more serious.  My guess is that they probably will wait until
it is all over.

> We draw a different conclusion as
> yours. And this is still needed to register cryto-chips at ANSSI,
> France, for security and also freedom.

The French crypto-laws are bizarre IMO.  I'm moving to France
in September :-)

Cheers
Anders

> 

Re: [Opensc-devel] Android 4.3 Hardware-Backed Security Features

[Jean-Michel P. - G. <jm...@go...>]

Le jeudi 29 août 2013 à 18:03 +0200, Anders Rundgren a écrit :
> JM, actual *usage* of certificates issued over the Internet in the
> EU already exceed that of smart cards for the reasons I have mentioned
> over and over: the lack of usable standards that doesn't require
> end-users to hang out in OpenSC list... 

Dear Anders,

This is not a reason for replacing security for a few with no security
for everyone. I don't get the point where hacked devices from design
should replace normal computers, just because they include a crypto
chip.

Now your project to work on Internet delivery of certificates is very
interesting, but it surely will never happen on G**** side, AFAIK. It
can only be your project or the project of another company. 

If you hang around Paris, just drop me an email, I will be glad to meet
you!

Kind regards,
-- 
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu