I see security as "journey" with no absolute end-destination. I'm sure that there will be screw-ups but it seems that iPhone and Android have fewer OS-level security breaches than Windows in spite of phones being "always connected".
The #1 security issue appears to be how to give apps the "right" privileges and telling them to user in a meaningful way. I honestly do not have any "silver bullets" to that so I concentrate on OS-level security which AFAICT actually have solutions although software bugs and complexity (as you mention), indeed can destroy even the best of intents. From a more practical point-of-view I'm fairly sure that efforts integrating external smart card support like seek-for-android and GlobalPlatform's consumer-centric security tokens, will be about as "successful" as WSIM was some 10 years ago. At least if something like the OpenSC is supposed to power it. Google and Apple cannot deal with such a complexity. I don't see that there even *could* be a scalable QA process for the traditional driver-per-card model. At best there will be built-in support for PIV and CAC. The lack of provisioning standards is IMHO also contributing to the killing of external security elements as a viable security option for phones. I think that the smart card industry should begin to worry about SIM-cards. Virtualized SIMs may look quirky from a user-perspective but I believe there are ways to deal with multiple/changed devices that in the end will make this model *more* convenient. "Secure Credential Cloning" has already been performed by banks in Sweden for *millions* of consumers so it obviously works. The only problem that is unique for SIMs is "multiple use" but I guess this can be addressed at the network level, particularly for LTE and forward that are based on IP. Anders On 2012-03-26 23:34, Frank Morgner wrote: > 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. > > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
