Re: Free Rootkit with Every New Intel Machine
[EMAIL PROTECTED] (Hal Finney) writes: The idea of putting a TPM on a smart card or other removable device is even more questionable from this perspective. It's not just questionable, it's a really, really bad idea. TPMs are fundamentally just severely feature-crippled smart cards. That is, they're optimised for doing DRM/secure boot/whatever-you-want-to-call-it, but in practice not much good for doing anything else (even if there are paper and Powerpoint-slide claims to the contrary). So you have something with all the drawbacks of a smart card (external widget that needs to be bought at extra cost and plugged in) and none of the advantages. Possibly with Vista's BitLocker disk encryption we will see more use of TPMs. BitLocker just uses the TPM as a glorified USB key (sealing a key in a TPM is functionally equivalent to encrypting it on a USB key). Since BitLocker isn't tied to a TPM in any way (I'm sure Microsoft's managers could see which way the wind was blowing when they designed it), it's not going to be TPM's killer app. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
Victor Duchovni [EMAIL PROTECTED] writes: Secure in what sense? Did I miss reading about the part of QKD that addresses MITM (just as plausible IMHO with fixed circuits as passive eavesdropping)? It would be good to read the QKD literature before claiming that QKD is always unauthenticated. The generally accepted approach among the physics crowd is to use authentication with a secret keys and a universal family of has functions. Once QKD is augmented with authentication to address MITM, the Q seems entirely irrelevant. It's not if you care about perfect forward secrecy and believe that DH might be broken, and can't cope with or don't trust a Kerberos-like scheme. You can authenticate QKD with a symmetric mechanism, and get PFS against an attacker who records all the traffic and breaks DH later. See http://portal.acm.org/citation.cfm?id=863982dl=GUIDEdl=ACM for a citation and http://www.ir.bbn.com/documents/articles/gdt-sigcomm03.pdf for text, for a discussion of a system that uses regular IKE and AH to authenticate the control channel and uses the resulting bits to key ESP with AES or a one-time pad to get PFS against a DH-capable attacker. This all ran on NetBSD over 3 sites in the Boston area for several years. There are two very hard questions for QKD systems: 1) Do you believe the physics? (Most people who know physics seem to.) 2) Does the equipment in your lab correspond to the idealized models with which the proofs for (1) were done. (Not even close.) Because of (2) I wouldn't have confidence in any current QKD system. The one I worked on was for research, to address some of the basic systems issues, because the physics community concentrates on the physics parts. I am most curious as to the legal issue that came up regarding QKD. pgpVro7qtbxAH.pgp Description: PGP signature
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: David G. Koontz [EMAIL PROTECTED] writes: There are third party TPM modules, which could allow some degree of standardization: As I said in my previous message, just because they exist doesn't mean they'll do anything if you plug them into a MB with the necessary header (assuming you have a MB with the header, and it's physically compatible, and electrically compatible, and the BIOS is compatible, and ...). Which MBs have you plugged one of these TPMs into and had it work? I don't have the luxury of buying tchotchkes to prove a point. (Ya, I have no use for this stuff either). In view of Peters insistence it was worth looking harder. I picked on one motherboard, a Gigabyte GA-P3-DQ6 which has the 20 pin header for the IEI TPM pluggable. After an extensive investigation I found no direct evidence you can actually do as Peter states and roll your own building a TPM enabled system. That includes downloading the BIOS and trying to search it. Found evidence of a TPM driver, no hard proof though. Why the emphasis on doing this as an end user anyway? Heck you should have seen how hard it was to get DVDs to work with Windows98 on an Intel D815 motherboard as an end user. If took the same level of investigation, and I still got lucky. The information necessary is available to OEMs, not generally end users. Looking across various vendors motherboards you see statements in the specifications stating TPM v1.2 support which I'd be inclined to think means BIOS support. I looked for mention of the IEI motherboards, and found distributors, no mention of anyone actually using them other than for industrial use. The Fujitsu-Siemens motherboards with TPM were similarly for industrial use. The idea of system integrity makes sense for say industrial robotics. Wonder if someone thought of using ECC memory? I found a Foxconn motherboard with the same 20 pin connector. Didn't find it on their G33 motherboard (Bearlake). There was no mention of TPM support in any documentation for the G33 board. I downloaded the BIOS for the board with the connector, de-lharc'd it and searched for strings indicating TPM support. Didn't find any references at all. It appears to be an older Phoenix BIOS. Same story for Peter - no proof you could actually use it, worse still, nothing in the BIOS. I found a Supermicro C2SBA mother board (another G33 Bearlake) that you can buy today. TPM enabled, theres a jumper described in the manual to enable TPM, which allows the BIOS page for it to show up. Sounds like solid support. The manual only has the topside layout. The jumper is near the system front edge, and the closest silicon is the ICH9 Southbridge. Note that the LPC bus is on the Southbridge anyway and would interconnect to a TPM chip (as well as BIOS FLASH/ROM), There's a candidate chip near the front panel stuff not to close to the BIOS chip, I couldn't find a high enough resolution photo to read the label. There is no through hole connector footprint for an external TPM manual visible. If I wanted to buy a TPM motherboard today, I could, a brand new one, too. The manual has pictures of the TPM pages in the BIOS console. The BIOS should work. Around $164 in the U.S., real pretty too with all the copper cooling on it. Theres also indication of whitebox integrators using the intel motherboards with TPM in-built. No indications of volume, which is probably the real question. TPM may well end up being present ubiquitously. Smart cards may well end up being present ubiquitously. Hardware RNGs may well end up being present ubiquitously. NIC-based crypto may well end up being present ubiquitously. Biometric readers may well end up being present ubiquitously. Home taping is killing mus... oops, wrong list. Been there, done that, got the tchotchkes to prove it. I've seen zero evidence that TPMs are going to be anything other than a repeat of hardware RNGs, NIC-based crypto, biometric readers, and the pile of other failed hardware silver bullets that crop up every few years. Wait a year or two and there'll be some other magic gadget along to fix all our problems. I found a FIPS 140-2 compliance statement from Phoenix dated July 2006, that mentions all your silver bullets except the biometric readers and encrypting NIC. http://csrc.nist.gov/cryptval/140-1/140sp/140sp709.pdf Someone doesn't think they are all relegated to tchotchkes, just yet. I was surprised to hear Intels random number chip is still marketed, must still be used in Type 1 COMSEC stuff. There is indication that TPM is tied to fingerprint scanners on laptops, they could be a passing fad. It'd be nice to see someone demonstrating spoofing one. Found something else that supports Peters point of view. Found a web page claiming that Intels vPRO doesn't require a TPM chip. It isn't clear how closely aligned vPRO is to DMTF. As far as TPM and DMTF, most of the hits relating to the two can be traced
RE: Free Rootkit with Every New Intel Machine
Ian Farquhar writes: [Hal Finney wrote:] It seems odd for the TPM of all devices to be put on a pluggable module as shown here. The whole point of the chip is to be bound tightly to the motherboard and to observe the boot and initial program load sequence. Maybe I am showing my eternal optimist side here, but to me, this is how TPM's should be used, as opposed to the way their backers originally wanted them used. A removable module whose connection to a device I establish (and can de-establish, assuming the presence of a tamper-respondent barrier such as a sensor-enabled computer case to legitimize that activity) is a very useful thing to me, as it facilitates all sorts of useful applications. The utility of the original intent has already been widely criticised, so I won't repeat that here. :) Would that basically be the same as a removable smart card or crypto token? Those do exist and I agree that they have many useful applications. However their purpose is somewhat different from the TPM, which is more specialized. It also shows those interesting economics at work. The added utility of the TPM module (from the PoV of the user) was marginal at best despite all claims, yet it facilitated functionality which was contrary to most user's interests. The content industry tried to claim that the TPM module would facilitate the availability of compelling content - which they tried to sell as it's user utility - but like most of their claims it was a smoke and mirrors trick. At this point we are reduced to speaking hypothetically. The TPM has not provided either much benefit or much harm so far. It has not (AFAIK) been used to protect any content, for good or evil. It has instead only been used as a sort of glorified, non-removable smart card, which indeed does not provide much utility. Consequently, the razor-edged economics of the motherboard and desktop industry has comprehensively rejected TPM except in certain specialized marketplaces where higher profit margins are available (eg. Servers, corporate desktops). The chipset manufacturers have also failed to add this functionality to their offerings to date. Now Vista has added Bitlocker, which arguably adds a user valuable feature for which a TPM module is needed (yes, you can run it without TPM, but it's painful). I wonder if we'll start to see more TPM connectors appearing, or even full TPM modules on motherboards and cores on south bridge dies? I think the focus is likely still to be on laptop systems where the benefits of an encrypted file system are especially high. However if Bitlocker comes down to the lower level Vistas then we may see TPMs start to appear on lower end laptops. Personally, I'd like to see a TPM implemented as a tamper-respondent (ie. Self-powered) module mounted on the motherboard in a socket which allows removal detection. That way you get the flexibility of moving the module, with the safety of a programmed response to an unauthorized removal. Interesting idea, although it's not clear what you would do with it. The TPM architecture is enormously complex but it is entirely focused on binding a TPM to a platform. Breaking that rule would invalidate so much of the TPM design that you might do better starting with a new chip with its own functions and purpose. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Free Rootkit with Every New Intel Machine
On 26 June 2007 00:51, Ian Farquhar (ifarquha) wrote: It seems odd for the TPM of all devices to be put on a pluggable module as shown here. The whole point of the chip is to be bound tightly to the motherboard and to observe the boot and initial program load sequence. Maybe I am showing my eternal optimist side here, but to me, this is how TPM's should be used, as opposed to the way their backers originally wanted them used. A removable module whose connection to a device I establish (and can de-establish, assuming the presence of a tamper-respondent barrier such as a sensor-enabled computer case to legitimize that activity) is a very useful thing to me, as it facilitates all sorts of useful applications. The utility of the original intent has already been widely criticised, so I won't repeat that here. :) If you can remove it, what's to stop you plugging it into another machine and copying all your DRM-encumbered material to that machine? It's supposed to identify the machine, not the user. Sounds to me like what you want is a personally identifying cert that you could carry around on a usb key... cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
David G. Koontz wrote: I picked on one motherboard, a Gigabyte GA-P3-DQ6 which has the 20 pin header for the IEI TPM pluggable. After an extensive investigation I found no direct evidence you can actually do as Peter states and roll your own building a TPM enabled system. That includes downloading the BIOS and trying to search it. Found evidence of a TPM driver, no hard proof though. Why the emphasis on doing this as an end user anyway? Heck you should have seen how hard it was to get DVDs to work with Windows98 on an Intel D815 motherboard as an end user. If took the same level of investigation, and I still got lucky. The information necessary is available to OEMs, not generally end users. Looking across various vendors motherboards you see statements in the specifications stating TPM v1.2 support which I'd be inclined to think means BIOS support. I found another Gigabyte board GA-N680SLI-DQ6 with TPM, available from Ascent here in New Zealand. I looked at the BIOS for it. It was close to brand new and mentioned it would take loadable drivers and didn't have reference to TPM. This leads creedence to the requirement for OEM access to enable TPM. The TPM driver wasn't available on the download page for the board. This board has the IEI 20 pin connector on it. The IEI page provides no links to documentation. The page shows various software management interfaces that are specific to TPM chip vendors, so I looked for them up. There are three modules based on infineon, atmel and sinosun TPM chips. Looking at the Infineon TPM v1.2 page we see the complete information isn't publicly available. There is no indication of how to do PC-BIOS integration, no in depth datasheet/manual, etc. It's probably not possible to to implement under windows without a partnership. I checked the Atmel site and the public information there was sparse. The Sinosun site has some basic information on management software. These would require your're are in partnership, although I found an advertisement for the Sinosun TPM software management tools ($26.99 US) http://www.orbitmicro.com/global/20pinsinosuntpmmoduleswmanagementtool-p-4385.html Orbit Micro is a system integrator and IEI distributor and probably can provide a white box solution. You're still at the mercy of the Motherboard/PC vendor for BIOS support. The Supermicro motherboard with integrated TPM has a BIOS that is TPM aware.. It probably uses an ST19WP18-TPM-C from Standard Microsystems (Found by searching their FAQ, another board with TPM). There is some information on software development environment: http://www.st.com/stonline/products/families/smartcard/sc_support.htm This compares the three TPM chip versions: http://www.st.com/stonline/stappl/productcatalog/app?path=/comp/stcom/PcStComOnLineQuery.showresultquerytype=type=product$$view=tablequerycriteria=RNP139=1120.0 and prompted examination of the their pdf files, the sections on the back on software. The drivers are actually in ROM on the ST chips, with a flag system for the host BIOS, allowing the same BIOS to work with or without TPM. This may explain some of the lack of visibility in some BIOS images. The windows drivers are embedded, too. The -TMP-C version used by the Supermicro motherboard talks about the use of Embassy Security Center suite from Wave Systems. There is a right to use license transfered with the chip: http://www.st.com/stonline/press/news/year2004/p1499m.htm also mentioned: http://www.tonymcfadden.net/tpmvendors_arc.html#software The last link gives insight into the Atmel software, too. The IEI pluggable TPM module web page shows software interfaces from three different vendors for the three different chips it uses. The Winbond chip is shown being administered by Wave's ESC. No indication of licensing terms. For open source/linux afficionados there's jtpmtools: http://trustedjava.sourceforge.net/ (probably ripe for a tcl wrapper) And information on the Open Trusted Computing web site: http://www.opentc.net (http://www.wavesys.com/products/TPM_Matrix.html describes the currently available TPM products from various system vendors.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/23/07, Eugen Leitl [EMAIL PROTECTED] wrote: The general idea is that if you use keys in DNS to authenticate gateways Aye, that's the rub. Most hosts are in dynamic address space, and anything involving DNS will not fly. It is certainly a problem, but you can get around it partially even if your IP address is dynamically assigned: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client You do need to use a dynamic DNS server to handle your keys, but there are lots of those, and many do provide that service. Also, this is limited to initiate-only IPsec; it does not handle incoming connections. However, that may be enough for many client machines that live in dynamic address space. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
On Mon, 25 Jun 2007, Hal Finney wrote: The idea of putting a TPM on a smart card or other removable device is even more questionable from this perspective. A TPM which communicates via an easily accessible and tamperable bus is almost useless for the security concepts behind the Trusted Computing Group architecture. Even if a TPM is soldered to the motherboard it does not mean that unsoldering is an esoteric art. There is a difference between what media hypes about TPM and what TCG technical documents say [1]: It is not expected that a TPM will be able to defeat sophisticated physical attacks. The exception might be if there were additional hardware to encrypt the bus, but that is not part of the standard spec. Encrypted bus requires encryption cores on both ends and key distribution resistant to MitM attacks. I suspect that if you system already has so many crypto blocks in it, it would be cheaper to implement TPM inside. So this would allow a removable TPM but it has to be logically bound to the motherboard via cryptography, presumably something like an encrypted bus. To logically bound TPM to the motherboard it is enough for BIOS `loader' that hashes the rest of the BIOS, to include unique ID of the motherboard into the hash. [1] https://www.trustedcomputinggroup.org/groups/tpm/TPM_1_2_Changes_final.pdf -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Fri, Jun 22, 2007 at 08:21:25PM -0400, Leichter, Jerry wrote: BTW, on the quantum subway tokens business: In more modern terms, what this was providing was unlinkable, untraceable e-coins which could be spent exactly once, with *no* central database to check against and none of this well, we can't stop you from spending it more than once, but if we ever notice, we'll learn all kinds of nasty things about you. (The coins were unlinkable and untraceable because, in fact, they were *identical*.) Now, of course, they were also physical objects, not just collections of bits. The same is true of the photons used in quantum key exchange. Otherwise, it wouldn't work. We're inherently dealing with a different model here. Where it ends up is anyone's guess at this point. This relates back to the inutility of QKD as follows: when physical exchanges are required you cannot run such exchanges end-to-end over an Internet -- the middle boxes (routers, etc...) get in the way of the physical exchange. This too is a *fundamental* difference between QKD and classical cryptography. That difference makes QKD useless in *today's* Internet. IF we had a quantum authentication facility then we could build hop-by-hop authentication to build an Internet out of QKD and QA (quantum authentication). That's a *big* condition, and the change in security models is tremendous, and for the worse: since the trust chains get enormously enlarged. IMO, QKD's ability to discover passive eavesdroppers is not even interesting (except from an intellectual p.o.v.) given: its inability to detect MITMs, its inability to operate end-to-end across across middle boxes, while classical crypto provides protection against eavesdroppers *and* MITMs both *and* supports end-to-end operation across middle boxes. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Mon, Jun 25, 2007 at 08:23:14PM -0400, Greg Troxel wrote: 1) Do you believe the physics? (Most people who know physics seem to.) Yes. 2) Does the equipment in your lab correspond to the idealized models with which the proofs for (1) were done. (Not even close.) Does QKD address a real-world risk at a reasonable cost without unreasonable application constraints? If I am very concerned about PFS for secrets that must stay secure for decades and 521-bit ECDH is broken, yes I lose PFS. So there may be a market for fixed direct circuits used by a small number of agencies, but if I were a budget director I would spend the money elsewhere... I am most curious as to the legal issue that came up regarding QKD. Indeed, what was the legal question that got us here? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/26/07, Sandy Harris [EMAIL PROTECTED] wrote: It is certainly a problem, but you can get around it partially even if your IP address is dynamically assigned: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client You do need to use a dynamic DNS server to handle your keys, but there are lots of those, and many do provide that service. Also, this is limited to initiate-only IPsec; it does not handle incoming connections. However, that may be enough for many client machines that live in dynamic address space. I don't get it. Why is it so limited? Reverse DNS is not significantly more trustworthy than simply querying the remote host on a known port if you don't have DNSSEC. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Mon, Jun 25, 2007 at 08:23:14PM -0400, Greg Troxel wrote: Victor Duchovni [EMAIL PROTECTED] writes: Secure in what sense? Did I miss reading about the part of QKD that addresses MITM (just as plausible IMHO with fixed circuits as passive eavesdropping)? It would be good to read the QKD literature before claiming that QKD is always unauthenticated. Noone claimed that it isn't -- the claim is that there is no quantum authentication, so QKD has to be paired with classical crypto in order to defeat MITMs, which renders it worthless (because if you'll rely on classical crypto then you might as well only use classical crypto as QKD doesn't add any security that classical crypto, which you still have to use, doesn't already). The real killer for QKD is that it doesn't work end-to-end across middle boxes like routers. And as if that weren't enough there's the exhorbitant cost of QKD kit. The generally accepted approach among the physics crowd is to use authentication with a secret keys and a universal family of has functions. Everyone who's commented has agreed that authentication is to be done classically as there is no quantum authentication yet. But I can imagine how quantum authentication might be done: generate an entangled pair at one end of the connection, physically carry half of it to the other end, and then run a QKD exchange that depends on the two ends having half of the same entangled particle or photon pair. I'm no quantum physicist, so I can't tell how workable that would be at the physics-wise, but such a scheme would be analogous to pre-sharing symmetric keys in classical crypto. Of course, you'd have to do this physical pre-sharing step every time you restart the connection after having run out of pre-shared entabled pair halfs; ouch. Once QKD is augmented with authentication to address MITM, the Q seems entirely irrelevant. It's not if you care about perfect forward secrecy and believe that DH might be broken, and can't cope with or don't trust a Kerberos-like scheme. You can authenticate QKD with a symmetric mechanism, and get PFS against an attacker who records all the traffic and breaks DH later. The end-to-end across middle boxes issue kills this argument about protection against speculative brokenness of public key cryptography. All but the smallest networks depend on middle boxes. Quantum cryptography will be useful when: - it can be deployed in an end-to-end fashion across middle boxes OR - we adopt hop-by-hop methods of building end-to-end authentication And, of course, quantum kit has got to be affordable, but let's assume that economies of scale will be achieved once quantum crypto becomes useful. Critical breaks of public key crypto will NOT be sufficient to drive adoption of quantum crypto: we can still build networks out of symmetric key crypto (and hash/MAC functions) only if need be (with pre-shared keying, Kerberos, and generally Needham-Schroeder). There are two very hard questions for QKD systems: 1) Do you believe the physics? (Most people who know physics seem to.) 2) Does the equipment in your lab correspond to the idealized models with which the proofs for (1) were done. (Not even close.) But the only real practical issue, for Internet-scale deployment, is the end-to-end issue. Even for intranet-scale deployments, actually. I am most curious as to the legal issue that came up regarding QKD. Which legal issue? Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On 06/25/2007 08:23 PM, Greg Troxel wrote: 1) Do you believe the physics? (Most people who know physics seem to.) Well, I do happen to know a thing or two about physics. I know -- there is quite a lot you can do with quantum physics, and -- there is quite a lot you cannot do with quantum physics. I also know that snake-oil salesmen can lie about the physics just as easily as they lie about anything else. Since it's not clear what is meant by THE physics, it would be more meaningful to ask more-specific questions, namely: -- Do I believe in real physics? Yes. -- Do I believe in what Dr. Duck says about physics? Usually not. == One commonly-made claim about quantum cryptography is that it can detect eavesdropping. I reckon that's narrowly true as stated. The problem is, I don't know why I should care. The history of cryptography for most of the last 2000 years has been a cat and mouse game between the code makers and the code breakers. The consensus is that right now the code makers have the upper hand. As a result, Eve can eavesdrop all she wants, and it won't do her a bit of good. To say the same thing: It appears that in this respect, quantum cryptography takes a well-solved problem and solves it another way at higher cost and lower throughput. The cost/benefit ratio is exceedingly unfavorable, and seems likely to remain so. Meanwhile, it takes some less-well-solved problems and makes them worse. Consider for example traffic analysis. Since quantum encryption requires a dedicated hardware link from end to end, there is no hope of disguising who is communicating with whom. I am reminded of a slide that Whit Diffie used in one of his talks. It showed a house that was supposed to be protected by a picket fence. The problem was that the so-called fence consisted of a single picket, 4 inches wide and a mile high, while the other 99.9% of the perimeter was unprotected. Yes sirree, no eavesdropper is going to hop over that picket! One sometimes hears even stronger claims, but they are even more easily refuted. I've reviewed papers that claim quantum mechanics solves the key distribution problem but in fact they were using classical techniques to deal with all the hard parts of the problem. It reminds me of stone soup: if the ingredients include broth, meat, vegetables, seasoning, and a stone, I don't see why the stone should get credit for the resulting soup. Likewise, since a quantum key distribution system is in no ways better and in some ways worse than a classical system, I don't see why quantum cryptography should get credit for solving the problem. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote: Note that that RFC is Informational only. There were a bunch of perceived issues with it, although I think they were more purity disagreements than anything. FWIW, if you do *not* care about man-in-the-middle attacks (called active attacks in RFC 4322), the solution is much, much simpler than what is given in RFC 4322: everyone on the Internet agrees on a single pre-shared secret and uses it. You lose any authentication from IPsec, but if all you want is an encrypted tunnel that you will authenticate all or parts of later, you don't need RFC 4322. This was discussed many times, and always rejected as not good enough by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. That's pretty funny, actually, although I don't quite agree with the substance (surprise!) :) Seriously, for those who merely want unauthenticated IPsec, MITMs and all, then yes, agreeing on a globally shared secret would suffice. For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 2:49 PM -0500 6/26/07, Nicolas Williams wrote: On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote: This was discussed many times, and always rejected as not good enough by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. That's pretty funny, actually, although I don't quite agree with the substance (surprise!) :) Why, are you some sort or purist? :-) (For those outside the IETF, Nico is one of the main movers and shakers in BTNS, and is probably one of the main reasons it looks like it will actually finish its work.) Seriously, for those who merely want unauthenticated IPsec, MITMs and all, then yes, agreeing on a globally shared secret would suffice. Well, almost suffice. You also need a way of signalling before the Diffie-Hellman that this is what you are doing, but that's a trivial extension to both IKEv1 and IKEv2. For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Fully agree. BTNS will definitely give you more than just one-off encrypted tunnels, once the work is finished. But then, it should probably be called MMTBTNS (Much More Than...). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Tue, Jun 26, 2007 at 01:20:41PM -0700, Paul Hoffman wrote: For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Fully agree. BTNS will definitely give you more than just one-off encrypted tunnels, once the work is finished. But then, it should probably be called MMTBTNS (Much More Than...). I strongly dislike the WG's name. Suffice it to say that it was not my idea :); it created a lot of controversy at the time, though perhaps that controversy helped sell the idea (why would you want this silly, insecure stuff? because it enables this other actually secure stuff). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 3:26 PM -0500 6/26/07, Nicolas Williams wrote: I strongly dislike the WG's name. Suffice it to say that it was not my idea :); it created a lot of controversy at the time, though perhaps that controversy helped sell the idea (why would you want this silly, insecure stuff? because it enables this other actually secure stuff). Whereas I was in the camp of liking the name very much for the very reason that this thread was started: because it lets you encrypt an arbitrary conversation with essentially no startup cost. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
On Jun 25, 2007, at 7:23 PM, Matt Johnston wrote: On Mon, Jun 25, 2007 at 04:42:56PM +1200, David G. Koontz wrote: Apple (mis)uses TPM to unsuccessfully prevent OS X from running on non-Apple Hardware. All Apple on Intel machines have TPM, that's what 6 percent of new PCs? To nit pick, the TPM is only present in some Apple Intel machines and isn't used in any of them. See http://osxbook.com/book/bonus/chapter10/tpm/ Their OS decryption key is just stored in normal firmware, unprotected AIUI. They've apparently stopped shipping TPMs. There isn't one on my MacBook Pro from last November, and it is missing on my wife's new Santa Rosa machine. If you want to see if a machine has one, then the command: sudo ioreg -w 0 | grep -i tpm should give something meaningful. Mine reports the existence of ApplePCISlotPM, but that's not the same thing. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
