IBM Lost Tape(s)
Apparently, last February IBM lost some tapes with employee data. Yesterday, I received a notification from them, which I scanned and put (slightly redacted) in http://www.tla.org/private/ibmloss1.pdf for your amusement. Now, I haven't worked for IBM in a long time, and since then I have moved about a dozen times. I'm pretty sure quite a few people are in that situation. I wonder how much it cost them to find current addresses for everybody so we could be notified. /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
luks disk encryption benchmarks
I just did some performance testing on a file server (debian 4.0) and thought I'd share the figures, both raw and using the luks cryptosystem described here: http://luks.endorphin.org/about Here's the specs: AMD Athlon 64 x2 3600+ (1800MHz) 2GB 800MHz DDR2 ECC DRAM Asus M2N32WS motherboard 3ware 9650SE SATA RAID controller (PCI Express) in PCI Express x16 slot 4 Seagate SATA-II 500GB 7200 RPM drives with NCQ in RAID 10 configuration 16kB stripe size Debian 4.0 stable (etch) # time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 23.0923 seconds, 45.4 MB/s real0m23.094s user0m0.000s sys 0m4.508s Now here demonstrates the luks cryptsetup overhead: # time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 31.0872 seconds, 33.7 MB/s real0m31.089s user0m0.004s sys 0m14.053s So, with write-caching disabled, performance is fairly close. Then I enabled write-caching and got this: # time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.08291 seconds, 340 MB/s real0m3.126s user0m0.000s sys 0m1.996s That seems to reflect that it isn't really going to disk. I'm surprised the controller has that much RAM on it, really... so I ran this: # time dd if=/dev/zero of=/dev/sdb bs=1024k count=4000 4000+0 records in 4000+0 records out 4194304000 bytes (4.2 GB) copied, 81.0223 seconds, 51.8 MB/s real1m21.024s user0m0.004s sys 0m19.197s Now here's the overhead with encryption: # time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=4000 4000+0 records in 4000+0 records out 4194304000 bytes (4.2 GB) copied, 151.202 seconds, 27.7 MB/s real2m31.227s user0m0.008s sys 1m29.318s Based on this, it looks like one of two things is happening: Write cache is 2GB and encryption cancels it out OR Encryption reduces bandwidth by about a factor of 2 with write-caching enabled. Now, for these filesystem tests I just used the default ext3... it does use a journal, which will slow down writes, but this should give ballpark figures: Here are the filesystem-level benchmarks without encryption (using LVM to make the filesystem 4G or so): Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP machine4G 54305 96 84213 14 37749 8 52767 94 119217 13 436.6 0 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 5175 99 + +++ + +++ 5131 99 + +++ 14419 99 machine,4G,54305,96,84213,14,37749,8,52767,94,119217,13,436.6,0,16,5175,99,+,+++,+,+++,5131,99,+,+++,14419,99 Here's the filesystem-level performance with encryption (again, with LVM on top of the encryption, file system 10G): Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP machine4G 36692 98 79380 71 28544 6 50631 91 74157 9 464.5 0 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 5344 99 + +++ + +++ 5261 99 + +++ 16060 99 machine,4G,36692,98,79380,71,28544,6,50631,91,74157,9,464.5,0,16,5344,99,+,+++,+,+++,5261,99,+,+++,16060,99 This presents a more interesting picture; it appears that for work on actual files, the overhead is pretty modest... with all but character-at-a-time input, it's not worth worrying about. My hunch is that over NFS, even with gigabit ethernet, there will be no measurable difference between encrypted and non-encrypted storage. -- ``To know love, be like the running brook, which though deaf, sings its melody for others to hear.'' -- Master Po, "Kung Fu" http://www.subspacefield.org/~travis/> -><- For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpHe5SIlTgbj.pgp Description: PGP signature
Why self describing data formats:
Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they need to get the data they expect. If they are looking for list of integer pairs, and they get a integer string pairs, then having them correctly identified as strings is not going to help much. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Security In Storage Workshop- Extended Deadline
Call for papers, submission deadline now June 15th. The 4th International Security In Storage Workshop will be held September 27, 2007 (Thursday) at Paradise Point Resort and Spa in San Diego, California, USA. The workshop is co-located with the 24th IEEE Conference on Mass Storage Systems and Technologies (MSST2007). Papers related to securing storage and circumventing secure storage are welcome. This includes databases, file systems, removable media, embedded systems, cell phones, etc. For more information, and submissions, see http://ieeeia.org/sisw/2007/ and the call for papers is at http://ieeeia.org/sisw/2007/SISW07CFP.pdf Please feel free to forward this email to other lists. Jim Hughes Program Chair SISW 2007
Re: A crazy thought?
Jim Dixon wrote: [snip] The CA certifies that X is your public key. ^ Who is you? That is the real question. To leave CAs out for the moment, imagine J. Doe and J. Doe, two different people, each put a public key on a server and you get a message created with a private key. You get the public key and validate it comes from one of the two J. Does. The question is who is the "real" J. Doe? Is one real and the other a repudiated key? Is one real and the other is trying to "steal" the identity of the other? Or is it simply that there are, indeed, two people with the same name? Adding a CA merely adds one layer of obfuscation and opportunity for false certification. If the CA starts handing out false public keys - which is the worst that it could do, right? - it will find itself instantly distrusted. Everybody in the world will be able to see that the CA used its private key to sign a false statement. Will they? What evidence do you have that "proves" the certificate is bogus? Say that the person who is having his identity stolen for whatever purpose discovers that there is a second certificate with his name on it but a different public key, what can he do, yell loudly, "No, I'm the real me!" How do we know that it isn't someone who is trying to muddy the waters and that the certificate holder is the real person? The offended party need only put the false declaration up on the Web. How many "The Boy Who Cried Wolf" cases would have to happen before we wouldn't trust *any* public key to represent who we think it does? How will dissident groups keep from getting compromised when fighting oppression? Best, Allen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
On Sat, 26 May 2007, Allen wrote: > Validating a digital signature requires getting the public key from > some source, like a CA, or a publicly accessible database and > decrypting the signature to validate that the private key associated > with the public key created the digital signature, or "open message." Yep. > Which lead me to the thought of trust in the repository for the > public key. Here in the USA, there is a long history of behind the > scenes "cooperation" by various large companies with the forces of > the law, like the wiretap in the A&TT wire room, etc. > > What is to prevent this from happening at a CA and it not being > known for a lengthy period of time? Jurors have been suborned for > political reasons, why not CAs? Would you, could you trust a CA > based in a country with a low ethics standard or a low regard for > human rights? The CA certifies that X is your public key. It doesn't know what your private key is. If the CA starts handing out false public keys - which is the worst that it could do, right? - it will find itself instantly distrusted. Everybody in the world will be able to see that the CA used its private key to sign a false statement. The offended party need only put the false declaration up on the Web. -- Jim Dixon [EMAIL PROTECTED] cellphone 415 / 570 3608 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: A crazy thought?
On Sat 5/26/2007 at 8:59 PM Allen [EMAIL PROTECTED] wrote: > Validating a digital signature requires getting the public key from > some source, like a CA, or a publicly accessible database and > decrypting the signature to validate that the private key associated > with the public key created the digital signature, or "open message." No. Usually the signer's certificate is included with the message so you don't go anywhere to get Alice's certificate, but you verify it against a trusted root. > > Which lead me to the thought of trust in the repository for the > public key. Here in the USA, there is a long history of behind the > scenes "cooperation" by various large companies with the forces of > the law, like the wiretap in the A&TT wire room, etc. >From my perspective, the primary attack vector here is the Trusted Root CA list. If you can get the recipient to accept a new root, the forgery is pretty simple. If the end-user fails to validate the Trusted Root CA list and examine the certificate signature chain, then any trusted root CA could issue a cert with any "Subject" making any claim. And yes, being in the security business, I do check the certificate chain for my bank's on-line service before logging on. (I've also complained to them when they re-used a certificate from one host for another.) > What is to prevent this from happening at a CA and it not being > known for a lengthy period of time? Jurors have been suborned for > political reasons, why not CAs? Would you, could you trust a CA > based in a country with a low ethics standard or a low regard for > human rights? To some extent, CA's are all about policy. What steps were required to obtain a certificate? These vary from "I had control of an e-mail account at the time of certificate issuance." to "I've had my lawyer present a notarized copy of my letters of incorporation and 2 years of public financial statements". To me it's simple: Don't trust the root CA if you don't trust them to enforce their policies. Verisign has built a small business on this premise. -Piers - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 307 digit number factored
* Victor Duchovni: >> But no one is issuing certificates which are suitable for use with >> SMTP (in the sense that the CA provides a security benefit). As far >> as I know, there isn't even a way to store mail routing information in >> X.509 certificates. > > There is no need to store routing information: > > http://www.postfix.org/TLS_README.html#client_tls_limits > http://www.postfix.org/TLS_README.html#client_tls_levels > http://www.postfix.org/TLS_README.html#client_tls_verify > http://www.postfix.org/TLS_README.html#client_tls_secure > > The short summary is that full security is only available when the > receiving MX hosts have certs that match the recipient domain, Which runs into the same problem as HTTP because the set of recipient domain names is not known at the time the TLS handshake occurs. > or the sender is willing to manually (in his MTA configuration) bind > the recipient domain to the subject names (or in 2.5 fingerprints) > of the appropriate MX hosts. And if you use fingerprints, there is no need for PKI. And in my experience, PKI doesn't buy you that much if you need to configure per-client privileges and things like that. Using the DN instead of a fingerprint doesn't seem to be worth the trouble. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
Two birds with one shot. :) Ali, Saqib wrote: I am not sure what you are trying to achieve. The CA never has your private key. They are just signing a X.509 certificate that holds your public key. This way they are vouching that that you own the public. Even if you subpoena a CA they won't be able to decrypt any information encrypted with your public key. So having a separation-of-duty is not providing any additional security. Can you please elaborate on you are trying to achieve? I never said that the CA had your private key, only that they could validate an open message came from whomever held the private key associated with a given public key. I like going back to historical instances to illustrate issues because people can read about them from second sources and perhaps get clues about the issue they might not of otherwise. In this case I'll refer to a commonly acknowledged observation that the biggest financial backer of the Communist Party, USA, in the 1950s was the FBI. Another instance of a similar sort is that in many cases during the anti-Vietnam war years, the people advocating violent actions turned out to be paid agents of the FBI and other government agencies. And a third scenario to consider is the capture of German spies by the British and them using them to send both bogus and real intelligence back to their masters. PKI and other similar structures are an attempt to maintain confidentiality between two parties that are not present in the same room while at the same time assure each other that they are indeed talking to who they think they are. In the case of the FBI agents they were not talking to whom they though they were. With the German spies, they were, but the spies had been suborned with threats of the noose if they did not comply. Same problem, two different expressions. How do you trust who you are talking to is the person they represent themselves as? It is almost a side issue whether anyone else is privy to the contents of the conversation, important to prevent misuse and fraud by others, but not central to the first point: Identification. In a private e-mail a suggestion was made that it might be possible for a CA to issue a second certificate alleging it to be yours but in fact it belonged to someone else. In this case which is the real you as represented by the conflicting certificates? Then Ian G wrote: [snip] As a side note, outside the cryptography layer, there are legal, contractual, customary defences against the attacks that you outline. Ah, yes, the rule of law. Well, I think we've seen enough with the Real Innocence Project validating that people are put to death with customary "legal" processes and that Guantanamo Bay exists to say that if the law is your only protection you need help in a big way if someone gets a burr up their butt about you. My goal in this discussion examine how we can keep the underlying issues clear and utilize tools, like cryptography, to assist us in achieving well founded trust relationships. Best, Allen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
Allen, I am not sure what you are trying to achieve. The CA never has your private key. They are just signing a X.509 certificate that holds your public key. This way they are vouching that that you own the public. Even if you subpoena a CA they won't be able to decrypt any information encrypted with your public key. So having a separation-of-duty is not providing any additional security. Can you please elaborate on you are trying to achieve? Thanks saqib http://www.full-disk-encryption.net On 5/26/07, Allen <[EMAIL PROTECTED]> wrote: Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told "impossible." Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the "impossible" mantra got me to thinking about it and wondering what vectors might make this possible. Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or "open message." Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes "cooperation" by various large companies with the forces of the law, like the wiretap in the A&TT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of "separation of duties" like two CAs located in different political environments might be used to accomplish this by having each cross-signing the certificate so that the compromise of one CA would trigger an invalid certificate. This might work if the compromise of the CA happened *after* the original certificate was issued, but what if the compromise was long standing? Is there any way to accomplish this? Thoughts? Best to all, Allen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
Allen wrote: Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of "separation of duties" like two CAs located in different political environments might be used to accomplish this by having each cross-signing the certificate so that the compromise of one CA would trigger an invalid certificate. This might work if the compromise of the CA happened *after* the original certificate was issued, but what if the compromise was long standing? Is there any way to accomplish this? What you are suggesting is called Web of Trust (WoT). That's what the PGP world does, more or less, and I gather that the SPKI concept includes it, too. However, x.509 does not support it. There is no easy way to add multiple signatures to an x.509 certificate without running into support problems (that is, of course you can hack it in, but browsers won't understand it, and developers won't support you). (Anecdote 1: I pushed all of the Ricardo financial transaction stuff over to x.509 for a time in 1998, but when I discovered the lack of multiple sigs, and a few other things, I was forced to go back to PGP. Unfortunately, finance is fundamentally web of trust, and hierarchical PKI concepts such as coded into x.509, etc, will not work in that environment.) (Anecdote 2: over at CAcert they attempt to graft a web of trust on to the PKI, and they sort of succeed. But the result is not truly WoT, it is a hybrid, in that there is still only one sig on the cert, and we are back to the scenario that you suggest. Disclosure: I have something to do with CAcert...) So as a practical matter, that which is known as x.509 PKI cannot do this. For this reason, some critics have relabeled the CAs as Centralised Vulnerability Parties (CVPs) instead of the more familiar Trusted Third Parties (TTPs). As a side note, outside the cryptography layer, there are legal, contractual, customary defences against the attacks that you outline. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
The need for off-line communication [was: Re: 307 digit number factored]
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > ... [lengthy discussion about why on-line communication is better > than off-line for strangers becoming introduced to one another] ... That may well be, but no claim was made that off-line communication is as efficient as on-line for introducing and certifying strangers to one another. It was only claimed that players who have to remain geographically hidden would lose their protection if deprived of off-line communication. This is because in the on-line, low-latency case, an attacker can locate the end-points through traffic analysis. Only off-line does the option exist of untraceable traffic mixing such as remailer chains. This subject is on-topic here because cryptography is an indispensable ingredient of these untraceable traffic mixes. -- StealthMonger <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. http://stealthsuite.afflictions.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
proceedings from ECRYPT Hash Workshop 2007
The workshop was very interesting. Will the presentations or papers be avalilable on the web soon? http://events.iaik.tugraz.at/HashWorkshop07/program.html Vlastimil Klima - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
LA Times: US funds super wiretap system for Mexico
http://www.latimes.com/news/nationworld/world/la-fg-mexico25may25,0,7011563.story?coll=la-home-center Mexico to boost tapping of phones and e-mail with U.S. aid Calderon is seeking to expand monitoring of drug gangs; Washington also may have access to the data. By Sam Enriquez, Times Staff Writer May 25, 2007 MEXICO CITY - Mexico is expanding its ability to tap telephone calls and e-mail using money from the U.S. government, a move that underlines how the country's conservative government is increasingly willing to cooperate with the United States on law enforcement. The expansion comes as President Felipe Calderon is pushing to amend the Mexican Constitution to allow officials to tap phones without a judge's approval in some cases. Calderon argues that the government needs the authority to combat drug gangs, which have killed hundreds of people this year. Mexican authorities for years have been able to wiretap most telephone conversations and tap into e-mail, but the new $3-million Communications Intercept System being installed by Mexico's Federal Investigative Agency will expand their reach. The system will allow authorities to track cellphone users as they travel, according to contract specifications. It includes extensive storage capacity and will allow authorities to identify callers by voice. The system, scheduled to begin operation this month, was paid for by the U.S. State Department and sold by Verint Systems Inc., a politically well-connected firm based in Melville, N.Y., that specializes in electronic surveillance. Although information about the system is publicly available, the matter has drawn little attention so far in the United States or Mexico. The modernization program is described in U.S. government documents, including the contract specifications, reviewed by The Times. They suggest that Washington could have access to information derived from the surveillance. Officials of both governments declined to comment on that possibility. "It is a government of Mexico operation funded by the U.S.," said Susan Pittman, of the State Department's Bureau of International Narcotics and Law Enforcement Affairs. Queries should be directed to the Mexican government, she said. Calderon's office declined to comment. But the contract specifications say the system is designed to allow both governments to "disseminate timely and accurate, actionable information to each country's respective federal, state, local, private and international partners." Calderon has been lobbying for more authority to use electronic surveillance against drug violence, which has threatened his ability to govern. Despite federal troops posted in nine Mexican states, the violence continues as rival smugglers fight over shipping routes to the U.S.-Mexico border, as well as for control of Mexican port cities and inland marijuana and poppy growing regions. Nonetheless, the prospect of U.S. involvement in surveillance could be extremely sensitive in Mexico, where the United States historically has been viewed by many as a bullying and intrusive neighbor. U.S. government agents working in Mexico maintain a low profile to spare their government hosts any political fallout. It's unclear how broad a net the new surveillance system will cast: Mexicans speak regularly by phone, for example, with millions of relatives living in the U.S. Those conversations appear to be fair game for both governments. Legal experts say that prosecutors with access to Mexican wiretaps could use the information in U.S. courts. U.S. Supreme Court decisions have held that 4th Amendment protections against illegal wiretaps do not apply outside the United States, particularly if the surveillance is conducted by another country, Georgetown University law professor David Cole said. Mexico's telecommunications monopoly, Telmex, controlled by Carlos Slim Helu, the world's second-wealthiest individual, has not received official notice of the new system, which will intercept its electronic signals, a spokeswoman said this week. "Telmex is a firm that always complies with laws and rules set by the Mexican government," she said. Calderon recently asked Mexico's Congress to amend the country's constitution and allow federal prosecutors free rein to conduct searches and secretly record conversations among people suspected of what the government defines as serious crimes. His proposal would eliminate the current legal requirement that prosecutors gain approval from a judge before installing any wiretap, the vetting process that will for now govern use of the new system's intercepts. Calderon says the legal changes are needed to turn the tide in the battle against the drug gangs. "The purpose is to create swift investigative measures against organized crime," Calderon wrote senators when introducing his proposed constitutional amendments in March. "At times, turning to judicial authorities hinders or makes
Re: 307 digit number factored
On Thu, May 24, 2007 at 01:01:03PM -0400, Perry E. Metzger wrote: > > Even for https, it costs no more to type in "2048" than "1024" into > your cert generation app the next time a cert expires. The only > potential cost is if you're so close to the performance line that > slower RSA ops will cause you pain -- otherwise, it is pretty much > costless. For average people's web servers most of the time, > connections are sufficiently infrequent and RSA operations are "fast > enough" that it makes no observable difference. I don't buy it. I build HTTP load balancers for a living, and for basically all of our customers who use our HTTPS accelleration at all, the cost of 1024-bit RSA is already, by a hefty margin, with hardware assist, the limiting factor for performance. Look at the specs on some of the common accelelrator families sometime: 2048 bit is going to be quite a bit worse. Busy web sites that rely on HTTPS are going to pay a fairly heavy price for using longer keys, and not just in cycles: the few hardware solutions still on the market that can stash keys in secure storage, of course, can stash exactly half as many 2048-bit keys as 1024-bit ones. Users who care about HTTPS performance aren't as rare, I think, as you think. What's more frustrating is the slow rate at which accellerator vendors have moved ECC products towards market. That's not going to help with adoption any. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
At 06:28 AM 5/27/2007, Allen wrote: Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or "open message." Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes "cooperation" by various large companies with the forces of the law, like the wiretap in the A&TT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? This (if I'm understanding you correctly) is exactly the thing that the web of trust [1] is intended to address. One issue with the web of trust is how to bootstrap it. My understanding is that in the case of PGP, this was handled by Zimmermann publishing his public key in the (dead-trees) version of his book. Udhay [1] http://en.wikipedia.org/wiki/Web_of_trust -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Free Rootkit with Every New Intel Machine
(Forwarded with permission from a NZ security mailing list, some portions anonymised) -- Snip -- [...] a register article saying Intel released its new platform Centrino Pro which includes Intel Active Management 2.5. An article with some more info is here: http://www.newsfactor.com/news/Intel-Debuts-Fourth-Gen-Centrino-Tech/story.xhtml?story_id=0210025GSEV9 It got me interested, so I started taking a look around. Intel has some good info here: http://softwarecommunity.intel.com/articles/eng/1032.htm And for all of you in the Web 2.0 generation with short attention spans for reading the doc, here is video that explains it all, I found myself getting more and more concerned the further it went: http://softwarecommunity.intel.com/videos/home.aspx?fn=3D1066 Essentially, all new Intel machines (and a number of current Intel servers) come with free hardware rootkit functionality, which is operational and accessible when the machine is powered off, and in the case of laptops, even when they are unplugged and powered off. There is the mention of code signing, TLS and PKI magic to allay your security concerns however... There are a few new things with this that go beyond generic remote IP KVM: - NIC based TCP/IP filters configurable remotely - Handy magic bypass for TCP/IP filters [1] - Remote BIOS updates over the network - Remote IDE redirection, as in boot off CDROM over the network - Persistent storage even if you change hard disks - It doesn't appear to have a method for disabling it (well, I can't find anything about it, seems crazy if there isn't) - Built-in, on chip. I can understand a decent size company wanting IP-KVM. But I don't want my personal laptop with IP-KVM. - Authentication can be done on Kerberos. We're talking AD. - Built in web interface on every machine (port 16994) - handy well documented SDK for building whatever you need to interact with this - ... This is clearly an awesome management tool. Being able to update your antivirus while your machine is disconnected from the network is helpful. Being able to id all your assets even though they are powered off is great. My concerns are around doomsday scenarios like the below: Worm is released that gets a domain admin account, worm sets up floppy booting across the network, floppy is boot-and-nuke [2]. Worm reboots every server in the company and securely wipes them with single pass. Worm then updates bios on every machine to broken state, enables TCP/IP filters to prevent the NIC from being used to talk to the OS ever again, then disables the AMT. Note, this is OS agnostic, will take out your OSX, Windows and Linux boxen. The hardware would probably be rendered useless, barring opening up the box and flipping some jumpers or replacing something. A smart user noticing the reboot and noticing the disk was being wiped (assuming you didn't change dban to say "now making your computer faster by optimizing the cache flux capacitor") would have to unplug power and network to stop it, which is harder if you're a laptop user with wireless. While parts of this are possible now, its just not nearly as powerful or ubiquitous. [1] TCP-over-Serial-over-LAN http://softwarecommunity.intel.com/articles/eng/1222.htm [2] http://dban.sourceforge.net/ -- Snip -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
Allen wrote: Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told "impossible." Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the "impossible" mantra got me to thinking about it and wondering what vectors might make this possible. CAs are certification authorities ... they certify some information they have checked and issue digital certificates that represent that checking ... somewhat analogous to physical licenses, credentials, certificates. most certification authorities aren't the authoritative agency for the information that they certify ... for the most part they are simply certifying that they have checked the information with whatever authoritative agency is responsible for that information. in that sense they are somewhat like notary ... i.e. if somebody has done some identity theft and managed to obtain a valid driver's license ... the notary isn't held responsible ... they just notarize that they checked a valid drivers license. this is somewhat the catch-22 scenario in recent posts for ssl domain name certification authorities http://www.garlic.com/~lynn/subpubkey.html#catch22 where they are in something of a situation because big part of the original justification for ssl domain name certificates involved integrity issues with the domain name infrastructure ... however, the domain name infrastructure is also the authoritative agency for domain name owner information, which the ssl domain name certification authority is dependent on as part of the integrity for certifying ssl domain name information. Fixing integrity issues in the domain name infrastructure ... improves the probability that correct ssl domain name certification is being performed ... but fixing integrity issues in the domain name infrastructure can also drastically reduce justification for having ssl domain name certificates. recent posts http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored in some cases, there is the possibility that the excessive attention to the details of the cryptographic operations is pure obfuscation that the rest of the end-to-end business processes may purely be built on a house of cards. for additional drift, some recent posts in related thread on digital certificates in another fora (including some possible infrastructure vulnerabilities and systemic risks) http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A crazy thought?
Allen wrote: > Hi Gang, > > In a class I was in today a statement was made that there is no way that > anyone could present someone else's digital signature as their own because no > one has has their private key to sign it with. This was in the context of a > CA certificate which had it inside. I tried to suggest that there might be > scenarios that could accomplish this but was told "impossible." Not being > totally clear on all the methods that bind the digital signature to an > identity I let it be; however, the "impossible" mantra got me to thinking > about it and wondering what vectors might make this possible. Awareness of the failure models of various PKI solutions is an important part of using and designing uses for them. There are many, many failure models for the current x509/Certification Authority model used by ssl. (everyone already familiar with the failure modes should probably hit "next message" now, unless they want to double check I am not giving out bad advice; this email is going to get rather long :) Consider the following steps. I will predefine three actors here - [SITE] which for email is the *recipient*, for web traffic is the server owner. [USER] which is the mail sender and/or site user - originator of protected data. [CA] which is the certificate authority 1. [CA] generates and stores securely a private key This is a once-in-a-decade event, but even so, there are failure modes. One possible mode is to use political pressure (or just bad coding) to force one of the two primes used in RSA to be either fixed or from a very small subset of possible primes (aka "canned primes"). As you can imagine, finding the private key becomes near trivial if you know one of the two primes in advance... We can move onto the security of the key later. 2. [CA] generates and stores a public certificate using the private key This at least is without any real issues (except security of the private key of course). In practice, this would be the same operation as (1) but need not be. 3. [CA] transmits the public key verifiably to the end recipients This is actually more complex than it sounds - I would guess 99% of the keys everyone has on their machine (if not 100%) were supplied to them with the browser, or in the case of IE, preinstalled on the machine. The vast majority of users have no idea how to even display those keys, never mind check them. To verify, ask yourself this question. For each web browser or email package installed to your machine, a) Where are root keys stored? b) How do I view them? c) Where is the public key or hash I should check? d) where do I obtain a known-good copy of that so I can verify it? The answers to some of those might surprise you (for instance, IE stores its root certs unprotected in the registry, and your AD administrator can override them at will; IE keys are used by almost everything supplied by microsoft, including execution digital signatures and email - Outlook or OE). All are trivially over-ridable by an attacker with write access to your machine. 4. [SITE] Generates and stores securely a private key Pretty much the same provisos apply here as did for the CA. Do you know and can you trust your key generation software? IIS for instance relies on a tool supplied my microsoft for the purpose; Apache usually suggests OpenSSL, email clients usually use their associated web browser for an interactive generation of both key and CSR while connected to the CA's website. However as another exercise - for each, where (and how) is the private key stored and protected? 5. [SITE] Generates and forwards to the CA a certificate signing request (CSR) Modulo the usual private key concerns, this is usually trouble-free (and again, is usually a combined step with key generation) 6. [CA] Receives and (for a payment) signs the CSR with its private key. This is where things get interesting. The certificate generated at this stage may or may not use exact copies of the data in the CSR; It may or may not be signed directly by the CA master key (for many CA's, their master key is kept offline in a bank vault and used to sign an intermediate key which is used for actual CSRs. In fact, it may sign *multiple* intermediate keys, for a number of good reasons (which we won't go into at this stage) but which also introduce another possible attack vector for a TLA with the power to force a CA of his choice (or someone with access to a private key there) to do selected tasks. Several potential attacks require that this transmission to the CA be intercepted and fulfilled by someone other than the CA themselves. Conventional wisdom says that there is little or no risk caused by site certificate substitution, and to a great extent this is correct - other than the possible forcing of the symmetric encryption method to one breakable by the TLA, there is little or no benefit to such a s
