2012/9/23 Anders Rundgren <anders.rundg...@telia.com>
> 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.
>
no, I was refering to all the magic solutions that make things secure
suddenly.
Like sms-tan instead of pin+tan, or funny devices reading flickering info
on some banks online system,
or smart cards with biometrics on board, or
$government-identified-super-secure-signing-cards or
stupid "de-mail" (email with a postage cost of half an euro) which they try
to sell in germany, and
all this stuff.
switching from magstripe to EMV transactions ("chip+pin") seams to be a
good idea though, as magstripe
is totaly unsecure. but the real foundation of the credit card business is
the middle man that vouches against
both user and shop for any loss, and runs a fraud prevention programm to
minimize risk and cost. this idea
is great, technical solutions are perfectly fine, if they keep this basic
system. I complain that they try to do not.
EMV is of course totaly bloated and thus far too complex, and the whole
idea of visa and mastercard keeping
paypass and paywave confidential, even partners under NDA only get to see
their bits, that is real stupid and insecure.
I wonder how many years we need until people are willing to build an online
only system. that won't work offline,
but could be soo much easier than the offline system. many banks have
already moved e.g. their PINs from the
card to the online system, as unblocking a PIN in a card was often not
working well, and having a central manged
IT is much easier. So banks are already willing to restrict at least
certain functions like debit (cash from ATM) to
online only.
>
> > 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.
>
well, no nfc in iphone5, thus no idea what plans Apple has, and I can't
comment on Google.
> > 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.
>
hmm. so if I designate my wife to be able to lockate and/or freeze and/or
fry/lock/... my phone,
and she does vice-versa, than anyone getting either fone can fry the other
phone as well?
ok, we can protect that with a password - but I need to remember it and
still it needs to be safe.
not easy to solve.
> 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 :-)
>
well, many apps in mobile phones are frontends for cloud services and keep
a local cache only.
thus we should have a backup in the cloud. but we loose a token to all
those parts of the cloud
as well. having a very limited number of SSO providers could be a good key
to improving security.
Andreas
>
> 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
