2012/9/22 Anders Rundgren <anders.rundg...@telia.com> > 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! >
actually I think the system was doing fine - if you can review transactions later and refute any bogus transaction and the money can be traced to the recipient, and the system provider has a huge interest to keep the money traceable and recall'able, that is a good system design, and protects everyone much better than technical adventures. The downside from my perspective is rather that visa and master card are shifting the liability to the end user. if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty bank account. Lets be honest: you might have your mobile phone and wallet in your hand-bag or backpack or whatever, and if both are stolen the attacker has access to about everything and almost all ways to identify you and authorize transactions are in his hand. even the numbers you might need to know to prevent fraud are no longer with you - e.g. in germany I might remember the central hotline for reporting stolen cards (116 116) and I remember my bank account number. but if they require my visa card number, I wouldn't know that. also I wouldn't have mobile phone with me - it got stolen - and if I don't notice the issue I'm out of luck, as everyone (banks, telco, ...) shift the liability for every transaction until the theft gets reported to the customer. the mobile phones have authentication of the customer (gesture, pin, password or screen unlock), but those are not very good protections. so my expectation is they won't stop attackers. Andreas > > 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 >
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
