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"
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 a
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 o
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 an
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 counterfeiti
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 tar
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 redu
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 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 p
>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 le
John Levine 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 attempts going
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
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 th
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 bounda
>> 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 howe
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
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 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, poo
> 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 co
On Wed, Nov 11, 2009 at 9:53 AM, 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
> management i
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 manageab
Ben Laurie 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 until you
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 simil
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*.
vulnerabi
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 ca
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 vulnerabilit
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 http://www
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 n
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, a
On Sun, Nov 8, 2009 at 7:07 AM, John Levine 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
Haven't read
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 proce
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 keylo
* 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
>
33 matches
Mail list logo