On 2012-09-23 12:04, Andreas Jellinghaus wrote: > 2012/9/22 Anders Rundgren <anders.rundg...@telia.com > <mailto: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.
I guess you refer to the Google Wallet or SKS as "technical adventures"? I don't see any conflicts between judicious logging and systems that [rightly or wrongly] are claimed to be more secure than passwords printed in clear on plastic cards. > > 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. 3D Secure IMO combines the worst possible user-interface with questionable security. However, the concept is actually brilliant but it will rather be Google and Apple that will make it useful, not MasterCard and VISA. > > 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. I expect another kind of protection to be more useful and that is that the owner will be able to set it "on hold" or possibly even in "wipe out" mode through a cloud service that the phone will interrogate every now and then. If the cloud service isn't available you must issue a "difficult" password before gaining access to the device. From what I can deduct from the rather scarce Wallet documents, this is more or less already in place. If the device is subject to a shrewd attack I guess only the traditional credential revocation will help. The cloud service may aid you with that as well. I definitely believe that losing a mobile phone wallet will be less devastating than losing a traditional one. Naturally it has to be proved. I believe there are a billion or so "guinea pigs" out there who are wiling to try :-) Anders > > 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 > <mailto: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 > <mailto: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
