On 2012-09-22 17:27, NdK wrote: > Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto: > >> In my mind keys could optionally contain application-oriented ACL >> telling which >> applications they trust so that even if you install a "bad" App, it >> would for >> example not be able to use your bank or eID-key in the background.
> In my mind, the SE should take over display and touch controller by > hardware means, so absolutely no app can snoop user input or fake it. > Too bad seems nobody really *needs* that level of security... The problem with that is that is impossible for a user to distinguish between a real PIN dialog and a fake ditto. The SKS' "work-around" to this particular issue is that there is an OS-based PIN dialog and that keys can specify that they only accepts PINs through the system PIN dialog (trusted path). If the user is presented a spoofed PIN dialog, the attacker may indeed get the PIN. However, the attacker must also take the device as well in order to use it which makes the attack much less useful. If the OS is hacked this doesn't help but it seems that this is not the biggest problem with mobile devices; it is rather determine what an app should be able to do or not. To get the proportions right, consumer security solutions should IMO be compared with the "Gold Standard" for Internet-payments where authorization is performed by a "UserID" (Card Number) and "Password" (CCV) printed in clear on plastic cards, which is all the Financial Industry have manged to roll out during the 15Y+ we have had with the Internet! Anders > >> I must admit I don't know how many apps are managed and seperated. given >> the restricted resources a smart card has, > Think about how an MMU works: it keeps a table of "pages" assigned to an > app, and maps 'em in app's address space. An app have no way to access a > page outside its allowed address space. Nothing secret, here, and > doesn't require great resources. > >> I only remember seeing code that would change master keys and put one >> app into a card, thus never bothered how it works in detail or how to >> manage resource, secure apps against each other etc. Also I wonder: does >> the vendor claim to have the security thight enough to prevent a hostile >> app from accessing data of another app? Or is it the usual "all is >> secure", but we don't tell how it works, >> how to use it, and make no real guaranties anyway? > Another question: if the applet manager is secure, then why change > master keys before giving a card to customers? > >> My new impression is I would only need to use a smart card key&cert with >> one site only - my SSO provider. Thus a plugin for that communication >> only would work well with me. > As long as you can import/export your cert (better if keeping it > protected by a password) then you can have quite good security using > openid and an identity provider like startssl that authenticates you > using that cert. > >> Not sure what to do about phone theft though - I really fear putting all >> the access credentials into one basket (my phone), plus a lot of >> personal information, so any thief would be able to >> impersonate me and access my mail, documents, banks, and much more. > For this I simply use keepass w/ its db synced over dropbox (and backed > up offline in multiple places). Obviously a thief wouldn't have my > master password, so the access to the db would be useless. > >> In summary: my old expectations how to secure communication and use >> smart cards in them have gone many months ago, now I see the "world" >> very differently. My adventures into smart card business also make me >> wonder if trusting such an industry is a good thing. > Always too many things under NDA or plainly unavailable, too often > starting from comm specs... > > BYtE, > Diego. > _______________________________________________ > 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
