Re: Dell to Add Security Chip to PCs
In message <[EMAIL PROTECTED]>, Dan Kaminsky writes: > >>>Uh, you *really* have no idea how much the black hat community is >>>looking forward to TCPA. For example, Office is going to have core >>>components running inside a protected environment totally immune to >>>antivirus. >>> >>> >> >>How? TCPA is only a cryptographic device, and some BIOS code, nothing >>else. Does the coming of TCPA chips eliminate the bugs, buffer overflows, >>stack overflows, or any other way to execute arbitrary code? If yes, isn't >>that a wonderful thing? Obviously it doesn't (eliminate bugs and so on). >> >> >> >TCPA eliminates external checks and balances, such as antivirus. As the >user, I'm not trusted to audit operations within a TCPA-established >sandbox. Antivirus is essentially a user system auditing tool, and >TCPA-based systems have these big black boxes AV isn't allowed to analyze. > >Imagine a sandbox that parses input code signed to an API-derivable >public key. Imagine an exploit encrypted to that. Can AV decrypt the >payload and prevent execution? No, of course not. Only the TCPA >sandbox can. But since AV can't get inside of the TCPA sandbox, >whatever content is "protected" in there is quite conspicuously unprotected. > >It's a little like having a serial killer in San Quentin. You feel >really safe until you realize...uh, he's your cellmate. > >I don't know how clear I can say this, your threat model is broken, and >the bad guys can't stop laughing about it. > I have no idea whether or not the bad guys are laughing about it, but if they are, I agree with them -- I'm very afriad that this chip will make matters worse, not better. With one exception -- preventing the theft of very sensitive user-owned private keys -- I don't think that the TCPA chip is solving the right problems. *Maybe* it will solve the problems of a future operating system architecture; on today's systems, it doesn't help, and probably makes matters worse. TCPA is a way to raise the walls between programs executing in different protection spaces. So far, so good. Now -- tell me the last time you saw an OS flaw that directly exploited flaws in conventional memory protection or process isolation? They're *very* rare. The problems we see are code bugs and architectural failures. A buffer overflow in a Web browser still compromises the browser; if the now-evil browser is capable of writing files, registry entries, etc., the user's machine is still capable of being turned into a spam engine, etc. Sure, in some new OS there might be restrictions on what such an application can do, but you can implement those restrictions with today's hardware. Again, the problem is in the OS architecture, not in the limitations of its hardware isolation. I can certainly imagine an operating system that does a much better job of isolating processes. (In fact, I've worked on such things; if you're interested, see my papers on sub-operating systems and separate IP addresses per process group.) But I don't see that TCPA chips add much over today's memory management architectures. Furthermore, as Dan points out, it may make things worse -- the safety of the OS depends on the userland/kernel interface, which in turn is heavily dependent on the complexity of the privileged kernel modules. If you put too much complex code in your kernel -- and from the talks I've heard this is exactly what Microsoft is planning -- it's not going to help the situation at all. Indeed, as Dan points out, it may make matters worse. Microsoft's current secure coding initiative is a good idea, and from what I've seen they're doing a good job of it. In 5 years, I wouldn't be at all surprised if the rate of simple bugs -- the buffer overflows, format string errors, race conditions, etc. -- was much lower in Windows and Office than in competing open source products. (I would add that this gain has come at a *very* high monetary cost -- training, code reviews, etc., aren't cheap.) The remaining danger -- and it's a big one -- is the architecture flaws, where ease of use and functionality often lead to danger. Getting this right -- getting it easy to use *and* secure -- is the real challenge. Nor are competing products immune; the drive to make KDE and Gnome (and for that matter MacOS X) as easy to use (well, easier to use) than Windows is likely to lead to the same downward security sprial. I'm ranting, and this is going off-topic. My bottom line: does this chip solve real problems that aren't solvable with today's technology? Other than protecting keys -- and, of course, DRM -- I'm very far from convinced of it. "The fault, dear Brutus, is not in our stars but in ourselves." --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: "The Reader of Gentlemen's Mail", by David Kahn
In message <[EMAIL PROTECTED]>, Bill Stewart writ es: >My wife was channel-surfing and ran across David Kahn talking about his >recent book >"The Reader of Gentlemen's Mail: Herbert O. Yardley and the Birth of >American Codebreaking". > >ISBN 0300098464 , Yale University Press, March 2004 > >Amazon's page has a couple of good detailed reviews >http://www.amazon.com/exec/obidos/ASIN/0300098464/qid=1105254301/sr=2-1/ref=pd >_ka_b_2_1/102-1630364-0272149 > I have the book. For the student of the history of cryptography, it's worth reading. For the less dedicated, it's less worthwhile. It's not "The Codebreakers"; it's not "The Code Book"; other than the title quote (and I assume most readers of this list know the story behind it), there are no major historical insights. The most important insight, other than Yardley's personality, is what he was and wasn't as a cryptanalyst. The capsule summary is that he was *not* a cryptanalytic superstar. In that, he was in no way a peer of or a competitor to Friedman. His primary ability was as a manager and entrepreneur -- he could sell the notion of a Black Chamber (with the notorious exception of his failure with Stimson), and he could recruit good (but not always great) people. But he never adapted technically. His forte was codes -- he know how to create them and how to crack them. But the world's cryptanalytic services were also learning how to crack them with great regularity; that, as much as greater ease of use, was behind the widespread adoption of machine cryptography (Enigma, M-209, Typex, Purple, etc.) during the interwar period. Yardley never adapted and hence he (and his organizations) became technologically obsolete. One of the reviews on Amazon.com noted skeptically Kahn's claim that Friedman was jealous of Yardley's success with women. I have no idea if that's true, though moralistic revulsion may be closer. But I wonder if the root of the personal antagonism may be more that of the technocrat for the manager... --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03)
In message <[EMAIL PROTECTED]>, "R. A. Hettinga" wr ites: > >--- begin forwarded text > > >Status: RO >From: Somebody >To: "R. A. Hettinga" <[EMAIL PROTECTED]> >Subject: Re: Wiretap Act Does Not Cover Message 'in Storage' For Short Perio >d (was Re: BNA's Internet Law News (ILN) - 2/27/03) >Date: Sun, 2 Mar 2003 14:09:05 -0500 > >Bob, > >Technically, since their signal speed is slower than light, even >transmission lines act as storage devices. > >Wire tapping is now legal. > No, that's not waht the decision means. Access to stored messages also requires court permission. The (U.S.) ban on wiretapping without judicial permission is rooted in a Supreme Court decision, Katz v. United States, 389 U.S. 347 (1967) (http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=case&court=us&vol=389&invol=347) which held that a wiretap is a search which thus required a warrant. I don't think there's ever been any doubt that seizing a stored message required a warrant. But in an old case (OLMSTEAD v. U.S., 277 U.S. 438 (1928)) the Court had held that the Fourth Amendment only protected material things, and therefore *not* conversations monitored via a wiretap. That decision was overturned in Katz. The crucial difference, from a law enforcement perspective, is how hard it is to get the requisite court order. A stored message order is relatively easy; a wiretap order is very hard. Note that this distinction is primarily statutory, not (as far as I know) constitutional. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: Did you *really* zeroize that key?
In message <[EMAIL PROTECTED]>, Peter Gutmann writes
:
>>[Moderator's note: FYI: no "pragma" is needed. This is what C's "volatile"
>> keyword is for.
>
>No it isn't. This was done to death on vuln-dev, see the list archives for
>the discussion.
>
>[Moderator's note: I'd be curious to hear a summary -- it appears to
>work fine on the compilers I've tested. --Perry]
>
Regardless of whether one uses "volatile" or a pragma, the basic point
remains: cryptographic application writers have to be aware of what a
clever compiler can do, so that they know to take countermeasures.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Re: DOJ proposes US data-rentention law.
In message <[EMAIL PROTECTED]>, "David G. Koontz" writes:
>Trei, Peter wrote:
>> - start quote -
>>
>> Cyber Security Plan Contemplates U.S. Data Retention Law
>> http://online.securityfocus.com/news/486
>>
>> Internet service providers may be forced into wholesale spying
>> on their customers as part of the White House's strategy for
>> securing cyberspace.
>>
>> By Kevin Poulsen, Jun 18 2002 3:46PM
>>
>> An early draft of the White House's National Strategy to Secure
>> Cyberspace envisions the same kind of mandatory customer data
>> collection and retention by U.S. Internet service providers as was
>> recently enacted in Europe, according to sources who have reviewed
>> portions of the plan.
>>
...
>
>If the U.S. wasn't in an undeclared 'war', this would be considered
>an unfunded mandate. Does anyone realize the cost involved? Think
>of all the spam that needs to be recorded for posterity. ISPs don't
>currently record the type of information that this is talking about.
>What customer data backup is being performed by ISPs is by and large
>done by disk mirroring and is not kept permanently.
This isn't clear. The proposals I've seen call for recording "transaction
data" -- i.e., the SMTP "envelope" information, plus maybe the From:
line. It does not call for retention of content.
Apart from practicality, there are constitutional issues. Envelope
data is "given" to the ISP in typical client/server email scenarios,
while content is end-to-end, in that it's not processed by the ISP. A
different type of warrant is therefore needed to retrieve the latter.
The former falls under the "pen register" law (as amended by the
Patriot Act), and requires a really cheap warrant. Email content is
considered a full-fledged wiretap, and requires a hard-to-get court
order, with lots of notice requirements, etc. Mandating that a third
party record email in this situation, in the absence of a pre-existing
warrant citing probable cause, would be very chancy. I don't think
even the current Supreme Court would buy it.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
