we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
...
My concern with that would be that if everyone uses the the same
signature scheme and token, the security of the entire industry
becomes dependent on the
On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote:
... we could moved to a person-centric paradigm ... where a person
could use the same token for potentially all their interactions ...
we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no
On 11/21/2009 04:56 PM, John Levine wrote:
we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
...
My concern with that would be that if everyone uses the the same
signature scheme and token, the security of the
On 11/21/2009 05:56 PM, Jerry Leichter wrote:
On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote:
... we could moved to a person-centric paradigm ... where a person
could use the same token for potentially all their interactions ...
we claimed we do something like two orders magnitude
leich...@lrw.com (Jerry Leichter) on Saturday, November 21, 2009 wrote:
It's no big deal to read these cards,
and from many times the inch or so that the standard readers require.
So surely someone has built a portable reader for counterfeiting the cards
they read in restaurants near big
On Nov 21, 2009, at 6:12 PM, Bill Frantz wrote:
leich...@lrw.com (Jerry Leichter) on Saturday, November 21, 2009
wrote:
It's no big deal to read these cards,
and from many times the inch or so that the standard readers require.
So surely someone has built a portable reader for
The FINREAD smart card reader was a European run at moving trust-bearing
transactions to an outboard device. It was a full Java VM in a
tamper-resistant box with a modest GUI, biometrics, lots of security on the
I/O ports and much attention to application isolation. FINREAD readers were
produced
On Fri, 2009-11-20 at 20:13 +1300, Peter Gutmann wrote:
Because (apart from the reasons given above) with business use specifically
you run into insurmountable PC - device communications problems. Many
companies who handle large financial transactions are also ones who, due to
concern over
Peter Gutmann wrote:
external data from finding its way onto their corporate networks (they are
really, *really* concerned about this). If you wanted this to work, you'd
need to build a device with a small CMOS video sensor to read data from the
browser via QR codes and return little more than
On 11/21/2009 06:31 PM, Jerry Leichter wrote:
Well, my building card is plain white. If anyone duplicated it, there'd be nothing
stopping them from going in. But then the actual security offered by those cards - and
the building controls - is more for show (and I suppose to keep the riffraff
On 11/18/2009 12:22 PM, Bill Frantz wrote:
Perhaps I'm missing something, but my multiple banks will all accept my
signature when made with the same pen. Why wouldn't they not accept my
signature when made with the same, well protected, signing/user verifying
device. I might have to take it to
On Wed, 18 Nov 2009, Bill Frantz wrote:
Perhaps I'm missing something, but my multiple banks will all accept
my signature when made with the same pen. Why wouldn't they not
accept my signature when made with the same, well protected,
signing/user verifying device. I might have to take it to
John Levine jo...@iecc.com writes:
I told him about an approach to use a security dongle that puts the display
and confirmation outside the range of the malware, and although I thought it
was fairly obvious, he'd apparently never heard it before.
Some general thoughts on this, there have been
In this case, heck, no. The whole point of this thing is that it is
NOT remotely programmable to keep malware out.
Which is perhaps why it is not a good idea to embed an SSL engine in such
a device.
Agreed. A display and signing engine would be quite adequate.
Such a device does however
jo...@iecc.com (John Levine) on Wednesday, November 18, 2009 wrote:
Such a device does however need to be able to suppor multiple mutually
distrusting verifiers, thus the destination public key is managed by
the untrusted PC + browser, only the device signing key is inside
the trust boundary. A
So should or should not an embedded system have a remote management
interface?
In this case, heck, no. The whole point of this thing is that it is
NOT remotely programmable to keep malware out.
If you have a modest and well-defined spec, it is well within our
abilities to produce reliable
On Nov 16, 2009, at 12:30 PM, Jeremy Stanley wrote:
If one organization distributes the dongles, they could accept
only updates signed by that organization. We have pretty good
methods for keeping private keys secret at the enterprise level,
so the risks should be manageable.
But even then,
On Mon, Nov 16, 2009 at 11:20:27PM -0500, Jerry Leichter wrote:
I'm not sure that's the right lesson to learn.
I might have, perhaps, phrased it a little better. Regardless of
initial planning, TI continued selling devices relying on this
particular code signing implementation well past what the
On Tue, Nov 17, 2009 at 01:35:12AM -, John Levine wrote:
So should or should not an embedded system have a remote management
interface?
In this case, heck, no. The whole point of this thing is that it is
NOT remotely programmable to keep malware out.
Which is perhaps why it is not a
Matt Crawford writes:
-+---
| Imagine a couple of hundred million devices with updatable
| firmware on them, and one or more rogue updates in the wild.
So should or should not an embedded system have a remote
management interface? If it does not, then a late discovered
flaw
On 11/10/2009 09:44 AM, Jerry Leichter wrote:
Not that this should block the use of devices like the ZTIC! They're
still much more secure than the alternatives. But it's important to keep
in mind the vulnerabilities we engineer *into* systems at the same time
we engineer others *out*.
On Nov 11, 2009, at 10:36 AM, Matt Crawford wrote:
On Nov 10, 2009, at 8:44 AM, Jerry Leichter wrote:
Whether or not it can, it demonstrates the hazards of freezing
implementations of crypto protocols into ROM: Imagine a world in
which there are a couple of hundred million ZTIC's or
Ben Laurie benl google.com writes:
Anyway, I should mention my own paper on this subject (with Abe
Singer) from NSPW 2008, Take The Red Pill _and_ The Blue Pill:
http://www.links.org/files/nspw36.pdf
In writing on page 2 that you do not need to secure what you
put in an Amazon shopping basket
On Wed, Nov 11, 2009 at 09:42:21PM -0500, Jerry Leichter wrote:
[...]
If one organization distributes the dongles, they could accept
only updates signed by that organization. We have pretty good
methods for keeping private keys secret at the enterprise level,
so the risks should be manageable.
On Wed, Nov 11, 2009 at 9:53 AM, d...@geer.org wrote:
Matt Crawford writes:
-+---
| Imagine a couple of hundred million devices with updatable
| firmware on them, and one or more rogue updates in the wild.
So should or should not an embedded system have a remote
On Nov 10, 2009, at 8:44 AM, Jerry Leichter wrote:
Whether or not it can, it demonstrates the hazards of freezing
implementations of crypto protocols into ROM: Imagine a world in
which there are a couple of hundred million ZTIC's or similar
devices fielded - and a significant
On 11/08/2009 02:07 AM, John Levine wrote:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process,
Jerry Leichter wrote:
On Nov 8, 2009, at 2:07 AM, John Levine wrote:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter
On Nov 8, 2009, at 7:45 PM, Thorsten Holz wrote:
...There are several approaches to stop (or at least make it more
difficult) this attack vector. A prototype of a system that
implements the techniques described in your blog posting was
presented by IBM Zurich about a year ago, see
* John Levine:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process, a botted PC can wait
On 08.11.2009, at 01:07, John Levine wrote:
I've made it an entry in my blog at
http://weblog.johnlevine.com/Money/securetrans.html
Actually this type of problem is pretty common in Europe, most banks
have to deal with malware that threatens their customers. One of the
most advanced
On Nov 8, 2009, at 2:07 AM, John Levine wrote:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login
On Sun, Nov 8, 2009 at 7:07 AM, John Levine jo...@iecc.com wrote:
So before I send it off, if people have a moment could you look at it
and tell me if I'm missing something egregiously obvious? Tnx.
I've made it an entry in my blog at
http://weblog.johnlevine.com/Money/securetrans.html
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process, a botted PC can wait
until you login, then
34 matches
Mail list logo
