On Saturday, March 24 at 07:07AM, Anders Rundgren wrote: > > http://www.globalplatform.org/specifications/review/GPD_SE_Access_Control_v0_10_0.pdf > > By adding ACL information to keys during enrollment you can limit key > "misuse" by bad apps. > > Although GP specifies a generic scheme not limited to SEs, the lack > of developments by the vendors of "connected" SEs (Smart Cards), > does in practice limit such features to embedded SEs like the > one supplied for the Google Wallet. > > In SKS/KeyGen2 I have taken this concept one step further by > allowing an issuer to specify that a PIN is only allowed through > a GUI running in a TEE (Trusted Execution Environment). That is, > if somebody spoofs a PIN dialog it won't give them SE access > "in the background".
You know that a trusted execution environment is not necessarily secure, right? For example, Xen, VMware and various sandboxes have been broken in the past. Simply put, complexity is the worst enemy of security. The real problem, that your solution addresses is the following: Lack of a trusted user interface is a major shortcoming of todays 2-factor authentication. Schneier wrote a nice and short article about that in 2005 (http://www.schneier.com/essay-083.html). > If the OS is broken nothing of this helps but that doesn't seem to be > the case with mobile trojans. They are mainly just bad apps. Assumptions, assumptions. Also, when you say "mainly" it seems that you believe that there are at least "some" real problems... You're free to assume that your (or some) phone is secure. But I am not so optimistic. I think, "secure enough" is the better label for hand-picked use cases on the phone. Cheers, Frank.
pgpWdxOcAnL0s.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
