& Subject: CRYPTO-GRAM, January 15, 2000% Date: Sun, 16 Jan 2000 21:12:34 -0600 / From: Bruce Schneier <schneier@counterpane.com> ! To: crypto-gram@chaparraltree.com                     CRYPTO-GRAM                 January 15, 2000                 by Bruce Schneier                 Founder and CTO)       Counterpane Internet Security, Inc. #            schneier@counterpane.com $           http://www.counterpane.com  F A free monthly newsletter providing summaries, analyses, insights, and3 commentaries on computer security and cryptography.   I Back issues are available at http://www.counterpane.com.  To subscribe or  unsubscribe, see below.   $ Copyright (c) 2000 by Bruce Schneier  . ** *** ***** ******* *********** *************   In this issue:0      "Key Finding" Attacks and Publicity Attacks%      Counterpane -- Featured Research 	      News $      New U.S. Encryption Regulations'      Counterpane Internet Security News       The Doghouse: Netscape       Block and Stream Ciphers       Comments from Readers  . ** *** ***** ******* *********** *************  ,  "Key Finding" Attacks and Publicity Attacks  E A couple of weeks ago the New York Times reported a new "key finding" I attack.  This was a follow-up to some research discussed here some months J ago, showing how to search for, and find, public and private cryptographic6 keys in software because of their random bit patterns.  E The company nCipher demonstrated that someone who has access to a Web I server that uses SSL can find the SSL private key using these techniques, K and potentially steal it.  nCipher's press release talked of "a significant D vulnerability to today's Internet economy."  Huh?  Why is this news?  J It's not the fact that the SSL private keys are on the Web server.  That'sG obvious; they have to be there.  It's not the fact that someone who has H access to the Web server can potentially steal the private keys.  That'sK obvious, too.  It's not the news that a CGI attack can compromise data on a H Web server.  We've seen dozens of those attacks in 1999.  Even the pressK release admits that "no information is known to have been compromised using E a 'key-finding' attack.  Neither nCipher nor the New York Times found K anyone who was vulnerable.  But wait . . . nCipher sells a solution to this # "problem."  Okay, now I understand.   H I call this kind of thing a publicity attack.  It's a blatant attempt by> nCipher to get some free publicity for the hardware encryptionH accelerators, and to scare e-commerce vendors into purchasing them.  And& people fall for this, again and again.  K This kind of thing is happening more and more, and I'm getting tired of it.   Here are some more examples:   C * An employee of Cryptonym, a PKI vendor, announced that he found a K variable with the prefix "NSA" inside Microsoft's cryptographic API.  Based D on absolutely zero evidence, this was held up as an example of NSA's# manipulation of the Microsoft code.   D *  Some people at eEye discovered a bug in IIS last year, completelyK compromising the product.  They contacted Microsoft, and after waiting only K a week for them to acknowledge the problem, they issued a press release and J a hacker tool.  Microsoft rushed a fix out, but not as fast as the hackersE jumped on the exploit.  eEye sells vulnerability assessment tools and   security consulting, by the way.  G I'm a fan of full disclosure -- and definitely not a fan of Microsoft's K security -- and believe that security vulnerabilities need to be publicized G before they're fixed.  (If you don't publicize, the vendors often don't K bother fixing them.)  But this practice of announcing "vulnerabilities" for > the sole purpose of hyping your own solutions has got to stop.  - Here are some examples of doing things right:   K *  The University of California Berkeley researchers have broken just about G every digital cellphone security algorithm.  They're not profiting from I these breaks.  They don't publish software packages that can listen in on 6 cellphone calls.  This is research, and good research.  G *  Georgi Guninski has found a huge number of JavaScript holes over the G past year or so.  Rather than posting scary exploits and cracking tools K that script kiddies could take advantage of, and rather than trying to grab H the limelight, he has been quietly publishing the problems and availableK workarounds.  Of course, the downside is that these bugs get less attention K from Microsoft and Netscape, even though they are as serious as many others I that have received more press attention and thus get fixed quickly by the 4 browser makers.  Nonetheless, this is good research.  G *  The L0pht has done an enormous amount of good by exposing Windows NT K security problems, and they don't try to sell products to fix the problems. K  (Although now that they've formed a VC-funded security consulting company, 7 @Stake, they're going to have to tread more carefully.)   G *  Perfecto markets security against CGI attacks.  Although they try to E increase awareness of the risks, they don't go around writing new CGI I exploits and publicizing them.  They point to other CGI exploits, done by G hackers with no affiliation to the company, as examples of the problem.   F * Steve Bellovin at AT&T labs found a serious hole in the Internet DNSG system.  He delayed publication of this vulnerability for years because # there was no readily available fix.   F How do you tell the difference?  Look at the messenger.  Who found theG vulnerability?  What was their motivation for publicizing?  The nCipher H announcement came with a Business Wire press release, and a PR agent whoG touted the story to reporters.  These things are not cheap -- the press F release alone cost over $1000 -- and should be an obvious tip-off that other interests are at stake.   K Also, look critically at the exploit.  Is it really something new, or is it H something old rehashed?  Does it expose a vulnerability that matters, orD one that doesn't?  Is it actually interesting?  If it's old, doesn'tK matter, and uninteresting, it's probably just an attempt at press coverage.   F And look at how it is released.  The nCipher release included a hackerG tool.  As the New York Times pointed out, "thus making e-commerce sites D more vulnerable to attack and more likely to buy nCipher's product."J Announcements packaged with hacker tools are more likely to be part of the" problem than part of the solution.  H I am a firm believer in open source security, and in publishing securityI vulnerabilities.  I don't want the digital cellphone industry, or the DVD I industry, to foist bad security off on consumers.  I think the quality of H security products should be tested just as the quality of automobiles is< tested.  But remember that security testing is difficult andE time-consuming, and that many of the "testers" have ulterior motives. J These motives are often just as much news as the vulnerability itself, and@ sometimes the announcements are more properly ignored as blatant self-serving publicity.   J The NY Times URLs using their search function change daily, but you can goH to http://search.nytimes.com/plweb-cgi/ and use the Extended Search; theK article title is "Attacks on Encryption Code Raise Questions About Computer  Vulnerability".    NCipher's press release:< http://www.ncipher.com/news/files/press/2000/vulnerable.html  ' NCipher's white paper (Acrobat format): < http://www.ncipher.com/products/files/papers/pcsws/pcsws.pdf  . ** *** ***** ******* *********** *************  &       Counterpane -- Featured Research  % "A Cryptographic Evaluation of IPsec"   & N. Ferguson and B. Schneier, to appear  H We perform a cryptographic review of the IPsec protocol, as described inH the November 1998 RFCs.  Even though the protocol is a disappointment --J our primary complaint is with its complexity -- it is the best IP security! protocol available at the moment.   % http://www.counterpane.com/ipsec.html   . ** *** ***** ******* *********** *************                       News  F You can vote via the Internet in the Arizona Democratic primary.  Does. anyone other than me think this is terrifying?C http://dailynews.yahoo.com/h/nm/19991217/wr/arizona_election_1.html   H An expert at the British government's computer security headquarters hasG endorsed open-source solutions as the most secure computer architecture 
 available:1 http://212.187.198.142/news/1999/50/ns-12266.html   I The DVD Copy Control Association is pissed, and they're suing everyone in  sight.3 http://www.cnn.com/1999/TECH/ptech/12/28/dvd.crack/   , Moore's Law and its effects on cryptography:7 http://www.newscientist.com/ns/20000108/newsstory2.html   + Information warfare in the Information Age: D http://www.cnn.com/1999/TECH/computing/12/30/info.war.idg/index.htmlD http://www.it.fairfax.com.au/industry/19991227/A59706-1999Dec27.html  J Radio pirates:  In the U.K., some radios can receive a digital signal thatH causes them to automatically switch to stations playing traffic reports.F Hackers have figured out how to spoof the signal, forcing the radio toE always tune to a particular station.  Good illustration of the hidden # vulnerabilities in digital systems. B http://news.bbc.co.uk/hi/english/sci/tech/newsid_592000/592972.stm, http://uk.news.yahoo.com/000106/18/d6jt.html   Well, this sure is inaccurate:) http://www.lancrypto.com/algorithms_e.htm   J Some months ago I mentioned the Y2K notice from Hart Scientific.  They now have a sequel:' http://www.hartscientific.com/y2k-2.htm    RSA "digital vault" software: : http://news.excite.com/news/pr/000111/ma-rsa-keon-software  H E-commerce encryption glitch; a good example of why people are the worstI security problem.  A programmer just forgot to reactivate the encryption. D http://news.excite.com/news/r/000107/17/news-news-airlines-northwest  K Become an instant cryptography portal.  Encryption.com, encryption2000.com,  and 1-800-ENCRYPT are for sale. 8 http://news.excite.com/news/bw/000111/wa-azalea-software http://www.encryption.com   C Mail encryption utility that lets you take back messages you regret 2 sending.  Does anyone believe that this is secure?8 http://www.zdnet.com:80/anchordesk/story/story_4323.html   Human GPS implants: 7 http://www.newscientist.com/ns/20000108/newsstory8.html    Clinton's hacker scholarships:1 http://chronicle.com/free/2000/01/2000011001t.htm   K Microsoft is building a VPN into Windows 2000.  Whose tunnel do you want to  hack today? 2 http://www.networkworld.com/news/2000/0110vpn.html  D Someone stole a bunch of credit card numbers from CD Universe, tried extortion, then posted some:9 http://www.wired.com/news/technology/0,1282,33563,00.html $ http://www.msnbc.com/news/355593.aspG and Cybercash's reaction (with a nice quote about how impregnable their > product's security is; way to wave a red flag at the hackers):C http://www.internetnews.com/ec-news/article/0,1087,4_279541,00.html   I An interesting three-part article about video surveillance and its effect  on society: 2 http://www.villagevoice.com/issues/9840/boal.shtml  K The system used to fund a series of anti-Bush commercials loosely resembles J my "street performer protocol," using the credit card company instead of aE publisher as a trusted third party.  They validate your card when you ; pledge, but only charge it if they get enough to run an ad:  http://www.gwbush.com/ Street performer protocol:0 http://www.counterpane.com/street_performer.html  I You can steal subway rides on the NY City system by folding the Metrocard I at precisely the right point.  The Village Voice and NY Times ran stories J about it, but those are no longer available, at least for free.  There's a copy of the NYTimes story here: 6 http://www.monkey.org/geeks/archive/9801/msg00052.htmlE The 2600 "Off the Hook" RealAudio for 2/3/98 talks about it, starting 1 around 54:35.  The RealAudio is linked from here: - http://www.2600.com/offthehook/1998/0298.html   F The White House released a national plan to protect America's computerK systems from unauthorized intrusions.  This plan includes the establishment H of the controversial Federal Intrusion Detection Network (FIDNET), whichJ would monitor activity on government computer systems.  (So far, there areA no plans to monitor commercial systems, but that can change.  The K government does want to involve industry in this.)  The plan also calls for A the establishment of an "Institute for Information Infrastructure E Protection" and a new program that will offer college scholarships to I students in the field of computer security in exchange for public service J commitments.  The scholarship program seems like a good idea; we need more computer security experts.  > http://www.thestandard.com/article/display/0,1151,8661,00.htmlJ http://dailynews.yahoo.com/h/ap/20000107/ts/clinton_cyber_terrorism_4.htmlE http://news.excite.com/news/ap/000107/01/tech-clinton-cyber-terrorism $ http://www.msnbc.com/news/355783.asp: http://www.computerworld.com/home/print.nsf/all/000107DB3A   EPIC analysis:! http://www.epic.org/security/CIP/  White House plan (PDF): L http://www.whitehouse.gov/WH/EOP/NSC/html/documents/npisp-execsummary-000105 .pdf White House press release:2 http://www.epic.org/security/CIP/WH_pr_1_7_00.html White House press briefing: 8 http://www.epic.org/security/CIP/WH_briefing_1_7_00.html  . ** *** ***** ******* *********** *************  &        New U.S. Encryption Regulations  H We have some, and they're a big improvement.  On the plus side, "retail"H encryption products -- like browsers, e-mail programs, or PGP -- will beI widely exportable to all but a few countries "regardless of key length or C algorithm."  On the minus side, the new regulations are complex (an I unending stream of work for the lawyers) and will still make it difficult I for many people to freely exchange encryption products.  They also do not K address the Constitutional free speech concerns raised by encryption export 	 controls.    Major features of the new regs:   J * "Retail" encryption products are be exportable, regardless of key lengthJ or algorithm, to all but the designated "T-7" terrorist nations.  In orderC to export you need to fill out paperwork.  You need to get a retail G classification, submit your product to a one-time technical review, and K submit periodic reports of who products are shipped to (but not necessarily  report end users).  I * Export of encryption products up to 64 bits in key length is completely  liberalized.  K * "Non-retail" products will require a license for many exports, such as to K foreign governments or foreign ISPs and telcos under certain circumstances.   J * Source code that is "not subject to an express agreement for the paymentF of a licensing fee or royalty for commercial production or sale of anyK product developed with the source code" is freely exportable to all but the H T-7 terrorist countries.  Source code exporters are required to send theF Department of Commerce a copy of the code, or a URL, upon publication.K Note that posting code on a web site for anonymous download is allowed; you C are not required to check that downloaders might be from one of the  prohibited countries.   K One obvious question is: "How does this affect the Bernstein and Karn court K cases?"  I don't know yet.  The free speech concerns are not addressed, but G the things that Bernstein and Karn wanted to do are now allowed.  We'll % have to see what the attorneys think.   K A more personal question is: "How does this affect the Applied Cryptography G source code disks?"  Near as I can tell, all I have to do is notify the I right people and I can export them.  I will do so as soon as I can.  Stay  tuned.   The actual regs (legalese): L http://www.eff.com/pub/Privacy/ITAR_export/2000_export_policy/20000112_crypt oexport_regs.html    EFF's press release:, http://www.eff.com/11300_crypto_release.html  ) Reuters story with BSA and Sun reactions: < http://news.excite.com/news/r/000112/19/tech-tech-encryption    Reuters story with EFF reaction:< http://news.excite.com/news/r/000113/13/tech-tech-encryption   AEA reaction press release: ; http://news.excite.com/news/pr/000112/dc-aea-encryption-reg    ACLU and EPIC reaction: < http://news.excite.com/news/zd/000113/18/crypto-compromise-a    . ** *** ***** ******* *********** *************  (       Counterpane Internet Security News  ) Bruce Schneier profiled in Business Week: L http://businessweek.com/cgi-bin/ebiz/ebiz_frame.pl?url=/ebiz/9912/em1229.htm  K Bruce Schneier is speaking at BlackHat in Singapore, 3-4 April 2000.  He'll , also be at BlackHat and DefCon in Las Vegas. http://www.blackhat.org  http://www.defcon.org   I Bruce Schneier is speaking at the RSA Conference in San Jose: Tuesday, 18 J Jan, 2:00 PM, on the Analyst's Track.  I don't know if it made it into theH program, but Bruce will be on stage with Matt Blaze, Steve Bellovin, and" several other really smart people.  . ** *** ***** ******* *********** *************  !            The Doghouse: Netscape   J Netscape encrypts users' e-mail passwords with a lousy algorithm.  If thisG isn't enough, their comments to the press cement their inclusion in the 	 doghouse:   J "Chris Saito, the senior director for product management at Netscape, saidH that the option to save a password locally was included for convenience.G Saito added that Netscape didn't use a stronger encryption algorithm to B protect passwords so that 'computer experts could still access the5 information, in case someone forgot their password.'"   ; In other words, they implemented lousy security on purpose.   H "Netscape's Saito said the company wasn't aware of the vulnerability andK added that a 'security fix' would be forthcoming if that vulnerability were K proved to exist.  If the Javascript vulnerability doesn't exist, a password I stealer would have to have physical access to a user's computer to figure  out the algorithm."   J Note the complete ignorance of viruses like Melissa, or Trojan horses like
 Back Orifice.   J "Saito noted that Netscape already has numerous safety features, includingH a Secure Sockets Layer, which enables users to communicate securely withA Web servers, and a protocol for encrypting e-mail messages sent."   0 None of which matters if the password is stolen.  = http://www.zdnet.com/zdnn/stories/news/0,4586,2409537,00.html    RST's information:+ http://www.rstcorp.com/news/bad-crypto.html 0 http://www.rstcorp.com/news/bad-crypto-tech.html  . ** *** ***** ******* *********** *************  #            Block and Stream Ciphers   C Block and stream ciphers both transform a message from plaintext to = ciphertext one piece at a time.  Block ciphers apply the same E transformation to every piece of the message, and typically deal with I fairly large pieces of the message (8 bytes, 16 bytes) at a time.  Stream K ciphers apply a different transformation to each piece  of the message, and K typically deal with fairly small pieces of the message (1 bit, 1 byte) at a  time.   G Traditionally they have been separate areas of research, but these days H they are converging.  And if you poke around at the issues a bit, you'll( see that they not very different at all.  K Stream ciphers first.  Traditional stream ciphers consist of three standard 7 pieces: an internal state, a next-state function, and a G plaintext-to-ciphertext transformation function.  The internal state is H generally small, maybe a hundred bits, and can be thought of as the key.G The next-state function updates the state.  The transformation function I takes a piece of plaintext, mixes it with the current state, and produces I the same size ciphertext.  And then the stream cipher goes on to the next  piece.  J The security of this scheme is based on how cryptographically annoying the: two functions are.  Sometimes just one of the functions isH cryptographically annoying.  In electronic stream ciphers, a complicatedI next-state function is usually combined with a simple transformation that H takes the low-order bit of the state and XORs it with the plaintext.  InH rotor machines, such as the German Enigma, the next-state function was aK simple stepping of various rotors, and the transformation function was very ? complicated.  Sometimes both are cryptographically complicated.   J These ciphers could generally operate in two modes, depending on the inputG into the next-state function.  If the only input was the current state, B these were called output-feedback (OFB) ciphers.  If there was theB additional input of the previous ciphertext bit, these were calledK cipher-feedback (CFB) ciphers.  (If you were in the U.S. military, you knew D these modes as "key auto-key" (KAK) and "ciphertext auto-key (CTAK),F respectively.)  And you chose one mode over the other because of errorD propagation and resynchronization properties.  (Applied Cryptography explains all this in detail.)   J Traditionally, stream cipher algorithms were as simple as possible.  TheseH were implemented in hardware, and needed as few gates as possible.  TheyI had to be fast.  The result was many designs based on simple mathematical D functions: e.g., linear feedback shift registers (LFSRs).  They wereC analyzed based on metrics such as linear complexity and correlation I immunity.  Analysts looked at cycle lengths and various linear and affine G approximations.  Most U.S. military encryption algorithms, at least the H ones in general use in the 1980s and before, are stream ciphers of these sorts.  I Block ciphers are different.  They consist of a single function: one that J takes a plaintext block (a 64-bit block size is traditional) and a key andH produces a ciphertext block.  The NSA calls these ciphers codebooks, andI that is an excellent way to think of them.  For each key, you can imagine K building a table.  On the left column is every possible plaintext block; on J the right column is every possible ciphertext block.  That's the codebook.E It would be a large book, 18 billion billion entries for the smallest B commonly used block ciphers, so it is easier to just implement theI algorithm mathematically -- especially since you need a new book for each I key.  But in theory, you could implement it as a single table lookup in a  very large codebook.  K Block ciphers can be used simply as codebooks, encrypting each 64-bit block E independently (and, in fact, that is called electronic codebook (ECB) B mode), but that has a bunch of security problems.  An attacker canI rearrange blocks, build up a portion of the codebook if he has some known E plaintext, etc.  So generally block ciphers are implemented in one of  several chaining modes.   J Before listing the block cipher chaining modes, it's worth noticing that aJ block cipher algorithm can serve as any of the functions needed to build aG stream cipher: the next-state function or the output function.  And, in I fact, that is what block cipher modes are: stream ciphers built using the G block cipher as a primitive.  A block cipher in output-feedback mode is K simply the block cipher used as the next-state function, with the output of E the block cipher being the simple output function.  A block cipher in K cipher-feedback mode is the same thing, with the addition of the ciphertext G being fed into the next-state function.  A block cipher in counter mode I uses the block cipher as the output function, and a simple counter as the I next-state function.  Cipher block chaining (CBC) is another block-cipher J mode; I've seen the NSA call this "cipher-driven codebook" mode.  Here theB block cipher is part of the plaintext-to-ciphertext transformation0 function, and the next-state function is simple.  J For some reason I can't explain, for many years academic research on blockG ciphers was more practical than research on stream ciphers.  There were B more concrete algorithm proposals, more concert analysis, and moreG implementations.  While stream cipher research stayed more theoretical, E block ciphers were used in security products.  (I assume this was the G reverse in the military, where stream ciphers were used in products and H were the target of operational cryptanalysis resources.)  DES's officialJ sanction as a standard helped this, but before DES there was Lucifer.  AndJ after DES there was FEAL, Khufu and Khafre, IDEA, Blowfish, CAST, and many more.   I Recently, stream ciphers underwent something of a renaissance.  These new I stream ciphers were designed for computers and not for discrete hardware. K Instead of producing output a bit at a time, they produced output a byte at K a time (like RC4), or 32 bits at a time (like SEAL or WAKE).  And they were F no longer constrained by a small internal state -- RC4 takes a key andF turns it into a 256-byte internal state, SEAL's internal state is evenK larger -- or tight hardware-based complexity restrictions.  Stream ciphers, J which used to be lean and mathematical, started looking as ugly and kludgyB as block ciphers.  And they started appearing in products as well.  I So, block and stream ciphers are basically the same thing; the difference K is primarily a historical accident.  You can use a block cipher as a stream K cipher, and you can take any stream cipher and turn it into a block cipher. J  The mode you use depends a lot on the communications medium -- OFB or CBCD makes the most sense for computer communications with separate errorJ detection, while CFB worked really well for radio transmissions -- and theH algorithm you choose depends mostly on performance, standardization, and popularity.   K There's even some blurring in modern ciphers.  SEAL, a stream cipher, looks G a lot like a block cipher in OFB mode.  Skipjack, an NSA-designed block I cipher, looks very much like a stream cipher.  Some new algorithms can be . used both as block ciphers and stream ciphers.  F But stream ciphers should be faster than block ciphers.  Currently theF fastest block ciphers encrypt data at 18 clock cycles per byte (that'sJ Twofish, the fastest AES submission).  The fastest stream ciphers are evenD faster: RC4 at 9 clock cycles per byte, and SEAL at 4.  (I'm using aG general 32-bit architecture for comparison; your actual performance may 5 vary somewhat.)  I don't believe this is an accident.   E Stream ciphers can have a large internal state that changes for every I output, but block ciphers have to remain the same.  RC4 has a large table I -- you can think of it as an S-box -- that changes every time there is an H output.  Most block ciphers also have some kind of S-box, but it remainsJ constant for each encryption with the same key.  There's no reason why youI can't take a block cipher, Blowfish for example, and tweak it so that the K S-boxes modify themselves with every output.  If you're using the algorithm J in OFB mode, it will still encrypt and decrypt properly.  But it will be aI lot harder to break for two reasons.  One, the internal state is a moving G target and it is a lot harder for an attacker to build model of what is ? going on inside the state.  Two, if the plaintext-to-ciphertext F transformation is built properly, attacks based on chosen plaintext orG chosen ciphertext are impossible.  And if it is a lot harder to break a G cipher with self-modifying internals, then you can probably get by with H fewer rounds, or less complexity, or something.  I believe that there isH about a factor of ten speed difference between a good block cipher and a good stream cipher.   J Designing algorithms is very hard, and I don't suggest that people run outH and modify every block cipher they see.  We're likely to continue to useK block ciphers in stream-cipher modes because that's what we're used to, and G that's what the AES process is going to give us as a new standard.  But I further research into stream ciphers, and ways of taking advantage of the G inherent properties of stream ciphers, is likely to produce families of ( algorithms with even better performance.  . ** *** ***** ******* *********** *************               Comments from Readers  , From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> Subject: German smart-card hack   J The note on "German hackers have succeeded in cracking the Siemens digitalG signature chip" in the 1999-12-15 CRYPTO-GRAM is wrong.  I have been in G contact with the German Hacker (Christian Kahlo) behind this story.  He I discovered that one user of the Siemens SLE44 chip series included in his F ROM software a routine that allowed him to upload and execute not onlyK interpreter bytecode, but also raw 8052 assembler instructions.  Using this G undocumented facility, Christian uploaded a tiny assembler program that K dumped the entire ROM of the card.  The ROM was investigated, posted on the @ USENET as a documented disassembler listing in a TeX file and noJ vulnerabilities were found.  Christian also discovered in the ROM that theG SLE chips send out the chip type and serial number when the I/O line is E held low during a positive reset edge and the following 600-700 clock C cycles, which is a perfectly normal feature (comparable to the BIOS K power-up message of a PC) that is fully documented in the SLE44 data sheets " and that is not security relevant.  J No smartcard applications were hacked this way, no vulnerability was foundA in any smartcard application, and definitely no private keys were K compromised.  All this also has nothing to do with digital signatures.  Any K news to the contrary is the result of misunderstandings by journalists, who C as usual fill in the gaps of the story with their limited technical A background knowledge and try to formulate such reports to be more F spectacular than the story behind them.  The only policy that has beenI violated here is that Siemens -- like most other smartcard chip producers E -- tries to make sure that nobody except big customers can easily get H access to smartcard development kits that allow to upload assembler code@ directly, which might otherwise shorten the learning curve for aG microprobing attacker slightly.  Users of Siemens chips that allow code F uploads are apparently required to use a bytecode interpreter instead.K This policy seems to have been ignored secretly by one Siemens customer who J left a backdoor in his byte-code interpreter to enable the later upload ofB high-speed crypto routines that cannot be implemented sufficiently efficient in the bytecode.  K Christian discovered this, even though he decided *not* publish the details H on how he did this or the name of the Siemens customer in whose cards heI had discovered this.  All he published was a dump of the standard Siemens G SLE ROM code (CMS = Chip Management System, comparable to a PC BIOS), a I piece of code that had already been known semi-publicly for many years in H the pay-TV hacking community from successful microprobing attacks on theH SLE44 series.  Christian's main contribution is that he has discovered aF very nice low-cost assembler-level development kit for some of the SLEH smartcards, which used to cost a fortune and an NDA before.  This is notJ the first time that this has happened: Pay-TV smartcards have been shipped before with software that J provides for uploads of EEPROM software patches with broken authenticationD techniques, which has been known and used in the smartcard tampering community for many years.    From: anonymous / Subject: Re: New U.S. Crypto Export Regulations   I In CRYPTO-GRAM of December 15, 1999 you wrote about the proposed new U.S. D crypto export regulations, and I can agree with everything you said.I However, I believe you missed something important: the view FROM the rest 
 of the world.   H I work in the finance industry in Europe -- Zurich, to be precise -- andI have some involvement with security.  This industry (a) WILL NOT use U.S. G crypto products, and (b) will certainly NOT make any long-term plans or J partnerships to do so for U.S. products with consumer content, because (a)J the products to date are forced by law to be weak, but more important, (b)K the U.S. government can't be trusted.  Even if it approved today the export A of some products based on strong crypto, everyone knows that this G permission could be terminated tomorrow for the same or other products. H And everyone also suspects strongly that the U.S. government will in any; case force providers to put trap doors into their products.   G Under the circumstances, the European finance and e-business industries I would be have to be crazy to use U.S. crypto-based products.  And they're 
 not crazy.  H To play in this business in the rest of the world, the U.S. will have toG have a clear, consistent, and favorable policy, and U.S. companies will I have to present products that are demonstrably strong with no trap doors. I (I invite you to speculate if this will happen before Hell freezes over.) J In the meantime, there are plenty of non-U.S. products to choose from, andF banks like UBS, Credit Suisse, Grupo Intesa, Societe General, DeutscheD Bank, Generale Bank, Bank Austria, and Barclays are not sitting backG anxiously waiting for U.S. products to become available.  They're doing > business with non-U.S. products that are just fine, thank you.  2 From: "Grawrock, David" <david.grawrock@intel.com> Subject: Electronic voting  F All these comments regarding electronic voting and absentee voting areE missing the mark.  The State of Oregon has that all elections (except E presidential) are done by mail.  It's like the entire state is voting 	 absentee.   I The process is actually pretty painless.  You receive your voter pamphlet G and then you get your ballot.  It has to be in by election day.  If you E miss the excitement of going to the voting booth there are collection J points where you can drop off your filled in ballot.  It's really not that hard.   F The point here is that the state has determined that it is easier (andH cheaper) to simply process the entire election via the absentee process.H It now becomes a simple step to go from by mail to by electronic voting.G All of the arguments regarding coercion must already have been answered E (the government always thinks a process through completely).  We have I elected all sorts of politicians without anyone coming back and reporting  problems with coercion.   & From: Gerry Brown <gerry@liberate.com> Subject: RE: Absentee Ballots   F I just checked some figures with a friend who has the data on AbsenteeJ Ballots for San Mateo County in California and he has compared it with the' San Francisco elections held this week.   C The percentage of registered voters using absentee ballots is about D 13%-15%.  But the more astonishing is the fact that 35%-50% of thoseF actually voting are done by absentee ballots.  The lower figure is forF national elections and the higher side corresponds to local elections.  ' From: "Hillis, Brad" <BradH@DIS.WA.GOV> ( Subject: PKI article--agree and disagree  C I can't begin to tell you how much I enjoyed your article with Carl I Ellison, "Ten Risks of PKI: What You're not Being Told about Public Key." G I'm the lead ecommerce attorney for the state of Washington, and we are J currently procuring a private PKI vendor to provide digital signatures forB state and local government, similar to the federal government ACES procurement.  F What you say that PKI is not needed for ecommerce to flourish is true.K It's a thought I keep having at all the digital signature law presentations F I attend, and the theme I had planned to discuss at my March 7 talk inG Boston on PKI.  One has to keep asking oneself, why do I need a digital H signature?  What is the opportunity cost of setting up a PKI?  (That is,I what security improvements could I make if I spent the money on something 
 besides PKI).   8 However, I disagree with this statement in your article:  B "In other words, under some digital signature laws (e.g., Utah andK Washington), if your signing key has been certified by an approved CA, then K you are responsible for whatever that private key does.  It does not matter G who was at the computer keyboard or what virus did the signing; you are  legally responsible."   J The law seems to say that at first reading, but my view of the law is thatK it sets up a "rebuttable presumption" of non-repudiation.  This is the same F rule that applies to physical, pen and ink signatures.  Your statementJ reflects the views of some proponents of PKI who overstate the legal forceK of a "licensed digital signature" under Washington law.  But if, in fact, I K never applied my digital signature to a document, and I can prove it (e.g., J I have an alibi), then I would not be legally responsible.  I believe thatH is the situation in non-PKI electronic signature schemes, where a (paperE and manually signed) Electronic Data Interchange Agreement or Trading H Partner Agreement will state that all data submitted between the parties: carries the same legal force as if it was manually signed.  K Having found flaws in the PKI-style laws of Washington, Utah and Minnesota, J I do not find a great deal of higher or practical intelligence in the moreK popular electronic signature laws, either.  Esignature laws have not proven K any more important to ecommerce than PKI digital signature laws, so why are D we in such a rush to pass UETA (uniform electronic transaction act)?  " From: "Carl Ellison" <cme@acm.org>- Subject: Re:  PKI article--agree and disagree   F You are correct.  However, I believe we still need to warn against theK rebuttable presumption of non-repudiation.  The keyholder may have no alibi J at all.  The keyholder may not be aware that his key was misused (e.g., byG an attacker who had gained physical or network access to his computer).   H This is similar to the position people were in in Britain when they wereC challenging ATM card operations.  It took expert witnessing by Ross G Anderson to defend some of their claims, and even then it didn't always H work.  There, too, the presumption was that the cardholder performed anyI operation when the ATM logs said he did -- whether he did or not.  It was + up to the cardholder to prove the negative.   J This gets even worse when the keyholder has his private key on a smartcardE in his possession.  It's that much harder to convince a jury that you I didn't sign, if the merchant or bank can claim that the signing key never K left your personal possession.  When an attacker has network access to your I computer, he doesn't leave a trail.  You have no audit record showing the J attack.  It's your word against the merchant's and you have no evidence toK offer on your behalf.  You can't even accuse anyone else.  You have no idea  who to accuse.  G Meanwhile, your account has been debited until you manage to prove your I point (against the presumption that you're lying).  When you compare this H to credit card purchases, it's radically different.  With a credit card,H you have not spent anything until you write the check to the credit cardG company.  When or before you write that check, you can challenge a line I item and force the merchant to prove that you were in fact the purchaser. I At  least with my AMEX account, the immediate result is that AMEX removes I the item from my statement -- to be reinstated if the merchant is able to G prove that I did do the purchase.  I have had such challenges go my way K once and the other times, I had simply forgotten.  In one case, I thought I K was being double-billed, but it turns out I had never been billed the first  time (many months before).  ; From: Alfred John Menezes <ajmeneze@cacr.math.uwaterloo.ca> % Subject: Elliptic Curve Cryptosystems   K I read with interest your recent article on ECC in the November 15 issue of @ Crypto-Gram.  I agree with most of your statements and comments.   Your recommendations were:J   1) If you're working in a constrained environment where longer keys just$ won't fit, consider elliptic curves.I   2) If the choice is elliptic curves or no public-key algorithms at all,  use elliptic curves.8   3) If you don't have performance constraints, use RSA.H   4) If you are concerned about security over the decades (and almost no systems are), use RSA.  K I certainly agree with recommendations 1) and 2) -- ECC certainly cannot be  worse than no security at all!  J Regarding recommendation 3), I think that most environments which call forC public-key solutions will have *some* performance constraints.  The H limiting factor could be an over-burdened web server which needs to signE thousands of outgoing messages per minute, a handheld device which is G communicating with a PC, etc.  In such scenarios, one should select the @ public-key method that performs the best in the most constrainedD environment.  If the constraints involve key sizes, bandwidth, powerJ consumption, or speed (for private key operations), then ECC is likely the method of choice over RSA.  I Finally, I feel that your recommendation that RSA should be used (instead J of ECC) in situations where you are concerned with long-term security is aK bit unfair.  After all, as you state in the postscript to your article, all K the analysis you used on the elliptic curve discrete logarithm problem also J applies to the integer factorization problem.  I propose that applicationsK which do require long-term security should consider using both* RSA and ECC K -- by double encrypting a message with RSA and ECC, or by signing a message  twice with RSA and ECC.   K The following are my condensed thoughts on the security and efficiencies of I ECC as compared with RSA.  They should be considered a supplement to your 1 Crypto-Gram article, and not a replacement of it.   H http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-article.html  E ((This is a good essay, but remember the author's bias.  He works for C Certicom, and it is in his financial interest for you to believe in  elliptic curves.  --Bruce))   . ** *** ***** ******* *********** *************  G CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, A insights, and commentaries on computer security and cryptography.   I To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a J blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe,K visit http://www.counterpane.com/unsubform.html.  Back issues are available  on http://www.counterpane.com.  J Please feel free to forward CRYPTO-GRAM to colleagues and friends who willK find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as   it is reprinted in its entirety.  I CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO of I Counterpane Internet Security Inc., the author of "Applied Cryptography," K and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served G on the board of the International Association for Cryptologic Research, I EPIC, and VTW.  He is a frequent writer and lecturer on computer security  and cryptography.   H Counterpane Internet Security, Inc. is a venture-funded company bringing8 innovative managed security solutions to the enterprise.   http://www.counterpane.com/   $ Copyright (c) 2000 by Bruce Schneier