Crypto-Gram February 15th, 2001

    Date15 Feb 2001
    Posted ByAnthony Pell
    This month's crypto-gram discusses Hard-Drive-Embedded Copy Protection, intentional back doors, NASA and eTrue, Internet voting issues, and more. " CPRM (Content Protection for Recordable Media) is a system for enforcing copy protection on personal computers. The basic idea is to enforce . . . This month's crypto-gram discusses Hard-Drive-Embedded Copy Protection, intentional back doors, NASA and eTrue, Internet voting issues, and more. " CPRM (Content Protection for Recordable Media) is a system for enforcing copy protection on personal computers. The basic idea is to enforce digital rights management -- copy-prevention, limited use, whatever -- in electronic media.

    In more detail, the scheme requires specially designed copying software. This software communicates directly to the disk drive, bypassing the operating system. To write a document, first the drive and the software authenticate to each other. Then the drive sends the software keying material that is stored in a nonstandard place on the drive that's unique to the medium, and also reads back an increment-only counter in the medium. The user-level application -- or, more likely, a server somewhere on the Web -- encrypts the file using that keying material. The encrypted object is written as an ordinary file on the medium. An intermediate key file is written as a second ordinary file.

      Date: Wed, 14 Feb 2001 23:17:01 -0600 To: This email address is being protected from spambots. You need JavaScript enabled to view it. From: Bruce Schneier <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: CRYPTO-GRAM, February 15, 2001                    CRYPTO-GRAM                 February 15, 2001                 by Bruce Schneier                 Founder and CTO        Counterpane Internet Security, Inc.             This email address is being protected from spambots. You need JavaScript enabled to view it.           <>   A free monthly newsletter providing summaries, analyses, insights, and  commentaries on computer security and cryptography.  Back issues are available at  <>.  To subscribe or  unsubscribe, see below.   Copyright (c) 2001 by Counterpane Internet Security, Inc.   ** *** ***** ******* *********** *************  In this issue:       Hard-Drive-Embedded Copy Protection       Crypto-Gram Reprints       News       Counterpane Internet Security News       An Intentional Backdoor       The Doghouse: NASA and eTrue       A Semantic Attack on URLs       E-mail Filter Idiocy       Air Gaps       Internet Voting vs. Large-Value e-Commerce       Comments from Readers   ** *** ***** ******* *********** *************       Hard-Drive-Embedded Copy Protection    CPRM (Content Protection for Recordable Media) is a system for enforcing  copy protection on personal computers.  The basic idea is to enforce  digital rights management -- copy-prevention, limited use, whatever -- in  electronic media.  In more detail, the scheme requires specially designed copying  software.  This software communicates directly to the disk drive, bypassing  the operating system.  To write a document, first the drive and the  software authenticate to each other.  Then the drive sends the software  keying material that is stored in a nonstandard place on the drive that's  unique to the medium, and also reads back an increment-only counter in the  medium.  The user-level application -- or, more likely, a server somewhere  on the Web -- encrypts the file using that keying material.  The encrypted  object is written as an ordinary file on the medium.  An intermediate key  file is written as a second ordinary file.  The "player" for these encrypted objects will pull an increment-only  counter out of the drive, use it and the keying material to decrypt the  intermediate key-file, and then extract the document key from that  file.  It will then play the document.  To move (as opposed to copy) the document to another disk, the software  will check to determine if this is permissible.  (Perhaps the permissions  will be embedded in the file; perhaps the software will query another  computer over the Internet.)  If the move is allowed, the software will  re-encrypt the document for the new medium (only allowing it to be stored  in a copy-protected medium), increment the increment-only counter in the  old medium, generate a new key-file key with the new counter value, and  rewrite the old key-file, deleting the key that would allow the old copy to  be played.  After moving the document, even if the user keeps a copy of the  encrypted bits, it won't play on the original medium because its key won't  be in the key-file on that medium.  If a user copies the encrypted object to another medium without going  through the approved procedure, its key won't be in the key-file on the new  medium, so the reader can't play it.  If the user copies both of them to  another medium, the key-file won't be decryptable since its key depends on  the medium-specific keying info.  If the user makes a backup copy of his  entire disk, "moves" the encrypted song onto another medium, then scrubs  and restores the entire original disk, the restored key-file won't be  decryptable, since the increment-only counter (that is hashed with the  medium-specific keys to produce the key-file key) will have changed.  There are other tricks built into the system.  There's no single global  secret to steal, and there's a mechanism to recover security if some of the  many global secrets get out.  The system is based on something called  "broadcast encryption," developed by Amos Fiat and Moni Naar in 1993.  The technology will be ineffective, but that may not matter.  Broadly speaking, there are three classes of people who copy  documents.  There are average users, who just want a second copy for  whatever reason but won't use hacker tools.  There are  more savvy users,  who are willing to download programs that break copy-protection  schemes.  And there are professionals, who are prepared to spend serious  money to break copy-protection schemes.  Against the first group, any security measure works.  This hardware scheme  is overkill.  Against the second group, any scheme that involves software  fails.  I've written about this extensively both in _Secrets and Lies_ (see  pp. 250-253) and in a previous issue of Crypto-Gram.  Basically, the scheme  described above has a key stored in hardware and a software decryptor.  To  break the scheme, you don't need to extract the hardware key.  You can let  the decryption software do it normally, and then grab the document after  decryption and before play.  Someone will write software do to this, just  as someone has written software to get around every other similar  scheme.  The hardware component doesn't matter.  Where it will make a difference is in devices that don't expose the  decrypted document.  The reason the computer embodiment fails is because  the document exists unencrypted in the computer, and a hacker can write a  program to take advantage of that.  If this copy protection is brought  forward to the video monitor, or the speakers, then the document never  exists in the computer in unencrypted form.  If the scheme only runs on DVD  players or MP3 devices or anything else where you can't run custom  software, this is much more effective.  But it still doesn't work against the third class of attackers: the  professionals.  These are people willing to invest in custom  hardware.  They will always be able to break these schemes and extract the  documents.  And they will always be able to produce and sell bootlegs, at  least to the limits of law enforcement in whatever country they're in.  There is another angle here, making this even more complicated.  Content  providers are no longer relying on technology to enforce copy protection,  they're relying on laws.  The algorithms used in this scheme will be  patented, so anyone who writes a hacked decoder will be infringing on the  patent.  And any software designed to circumvent this mechanism will be  illegal under the Digital Millennium Copyright Act.  Not only can the  authors of this software be prosecuted, but so can people who "traffic" in  this software: e.g., post or link to it on their Web site.  This will not make it any harder to find such circumvention software --  notice how easy it is to find DeCSS today with your search engine -- but it  will have a chilling effect on the whole idea.  2600 Magazine was  successfully prosecuted for linking to DeCSS; similar pressure will be  brought to bear against anyone who publicizes any DeCPRM software.  So, what do we have here?  We have a serious threat to civil liberties:  large entertainment companies are allying themselves with the computer  industry to dictate what can and can't happen on your hard drive.  (CPRM is  only supposed to be for flash memory.  This is a lie, of course.  Already  it is planned for IBM's tiny hard drive, and larger drives aren't far  behind.)  We have a technology that will, in some circumstances, make  backups impossible.  Compatibility problems between disk drives that have  CPRM and those that don't will force networks to completely upgrade their  mass storage.  We have a technology that forces users to buy proprietary  decoding software forever.  We have a technology that won't really work  unless it extends to computer output devices; you may find yourself forced  to upgrade your monitor as well to watch movies on your computer.  And we  have an increased reliance on legal harassment by media companies.  It's  that last bit that scares me the most.  The proposal: <> <> <> <> <>  What's Wrong with Copy Protection, by John Gilmore: <>  Copy protection and why it doesn't work: <>  EFF's archives on the topic: <>  The 4C Entity (IBM, Intel, Toshiba and Matsushita), which owns and  advocates CPRM: <>   ** *** ***** ******* *********** *************               Crypto-Gram Reprints    Distributed denial-of-service attacks: <  ceAttacks>  Publicizing vulnerabilities: <>  Recognizing crypto snake-oil: <>   ** *** ***** ******* *********** *************                        News    Nineteen technology companies have joined forces to share data on system  vulnerabilities and Internet threats.  Called the Information Technology  Information Sharing and Analysis Center (IT-ISAC), the group is supposed  work with the government to head off future cyberattacks on the group's  members.  I have very mixed feelings about this.  On the one hand, sharing  information is a good idea, and we need more of this.  On the other hand,  the problem with sharing information among group members is that it remains  a secret from the rest of the world.  The last thing we want is a divide of  haves and have-nots, with only those in special clubs being secure. <> <,4586,2674800,00.html> <,1283,41212,00.html>  Princeton University's Ed Felten is not going to publish details about how  he broke the Secure Digital Music Initiative (SDMI) watermark challenge,  because of the prosecution provisions of 1998 Digital Millennium Copyright  Act (DMCA). <> <>  A rebuttal to my essay last month about certifying security products: <>  The future of operating system security: <>  Latest news on U.S. crypto export controls: <,4586,2673461,00.html>  Testimony on evaluating voting machines.  He makes the point that voting  machines should never have secret or proprietary parts.  A bit long, but  worth reading. <> And a U.S. government report on the problems of computerized voting from  1988.  Lots of lessons that should be learned. <>  A Linux worm -- called Ramen -- is working its way through the  Internet.  Some consider this retribution for the smugness of Linux users  about the security of their operating system versus Windows.  That misses  the point; of course all operating systems will have vulnerabilities.  The  two interesting points are: 1) default installations of Red Hat Linux are  insecure, just like default installations of Windows, and 2) just because  patches exist for a vulnerability doesn't mean we're safe. <>  Why the government needs to protect individual privacy on the Internet,  while staying away from regulating content, information, and ideas. <>  A year after the highly publicized distributed denial-of-service attacks,  the Internet is still vulnerable: <>  The EFF has petitioned a federal appeals court to overturn a lower court's  interpretation of the DMCA to mean that the 2600 Web site must remove links  to DeCSS. <> <> <> <>  Leo Marks, WW II cryptographer and author of _Between Silk and Cyanide_ died: <>  Often, security vulnerabilities are never patched: <>  The 3G cell phone encryption algorithms are public.  This is a welcome  change from the industry's usual practice of secret cryptography.  Bravo. <>  After all these years, the Net still isn't a safe place (no surprise): <,1199,NAV65-663_STO56690_NLTs,00.html>  All vulnerability scanners miss things, but the open source (and free)  Nessus was judged to be the best: <>  Children are a significant personal privacy risk: <>  Master's thesis:  Cryptographic Software Export Controls in the EU. <>  DirecTV scored a direct hit against pirates.  Over the course of a few  months it surreptitiously broadcast, byte by byte, a program that allowed  it to permanently disable pirate DirecTV access cards.  On January 21st,  they triggered the program.  Supposedly this knocked out 98% of cracked  cards.  My favorite tidbit is that they wrote "GAME OVER" into an affected  area of memory.  The pirate community is already working on hardware  workarounds and, supposedly, the cracked cards that use emulation are easy  to fix.  So while DirecTV won this battle, the war goes on. <> <> <> <>  Basic cryptanalysis of RSA's formerly proprietary SecurID hash function. <>  The NSA is trying to design a hack-proof computer.  I don't know, but this  seems like a poorly thought out idea. <>  Classic snake oil: <> It's secret, and they even have a contest.  More snake oil: cryptanalysis of "Encrypted Magic Folders": <>  It seems that private keys are exposed in the Java security database.  This  explanation is worth reading. <>  A bunch of cryptographers, myself included, wrote an amicus brief for the  DeCSS case that EFF is supporting: <  us.html>  Optical vote readers can be worse than punch cards, according to a 28 Jan  01 LA Times article.  Some systems reject ballots because the voter marked  the oval for a candidate and then also wrote the same candidate's name in  the write-in space.  Personally, I don't see how that can be interpreted as  anything but "the clear intent of the voter."  My favorite blunder has to  be the counting machines that rejected mail-in absentee ballots because  they detected the fold in the paper (unavoidable in order to actually mail  the ballot in the legal envelope) as a second vote.  (If you want to read  the article online, you have to pay for it at  The idiots  only keep their links free for a few weeks.)  Excellent article on why micropayments don't make business sense. <>  Fascinating thought piece on the future of "digital rights management": <>  There have been reports that RSA has been cracked by a Filipino "math  enthusiast."  Actually, the cracking algorithm is slower than factoring. <,2000010021,20178050-1,00.htm> An e-mail conversation with Ron Rivest about the algorithm: <>  Crypto break of the 802.11 wireless LAN encryption protocol (Apple's  AirPort, for example).  Real-time decryption of traffic is possible.  Nice  work. <> <,4586,2681947,00.html> <,1282,41612,00.html>   ** *** ***** ******* *********** *************         Counterpane Internet Security News   Schneier's "Why Cryptography is Harder than it Looks" has been published on  a German Web site: <>   ** *** ***** ******* *********** *************               An Intentional Back Door    It's one thing have an attacker add a back door to your system for later  unauthorized access.  It's quite another to deliberately do it to yourself.  It seems that Borland did this very thing with its Interbase database.  All  versions released for the past seven years (versions 4.x through 6.01) have  this back door.  How it came about and how it was discovered is instructive.  Versions of Interbase before 1994 didn't have any access-control  mechanisms.  This was fixed in version 4.0 using a peculiar system.  Since  they had a database, the engineers created a special database within  Interbase for account names and encrypted passwords.  This solution had a  problem: in order to authenticate a user, the program had to access the  database, but before the program could access the database, it had to  authenticate a user.  Now there are many ways to solve this problem, but hard coding the username  "politically" and the password "correct" is not the one I would have  chosen.  But it is the one Borland did.  This is the backdoor; anyone using  that username and password can access any Interbase database.  Lesson one:  Deliberately adding back doors creates a security problem  whose magnitude is unknown and changes over time.  I call this the "window  of exposure."  The moment this product was shipped, the vulnerability  existed.  But as long as no one knew about it, it wasn't a problem.  At  this point we have no idea if anyone in the hacking underground knew about  the vulnerability, or if any criminals took advantage of it.  Certainly the  programmers who coded the "feature" knew about it.  They could have told  others.  Word could have gotten around.  Now the vulnerability is public; everyone knows about.  Within days of  announcement, there were reports of scans looking for the  vulnerability.  Borland issued a patch, but who knows what percentage of  users will patch their systems.  The vulnerability will remain in many  systems for years.  Lesson two: Open source helps security, sometimes.  Interbase was made open  source in July 2000.  This vulnerability was discovered six months later by  a German software developer.  If he hadn't discovered it, maybe we would  still not know about it.  If someone had looked at the code sooner, maybe  we would have known sooner.  Open source means that more people examine the  source code, but it is no guarantee that vulnerabilities will be found or  -- even if found -- fixed properly.  If the person who discovered the  vulnerability was intent on breaking into systems, this would have played  out much differently.  Lesson three:  In a world with no liabilities, trust is transitive whether  you like it or not.  Company X's customers trust Company X.  If Company X  was using Interbase, those customers were also trusting Borland...only they  didn't know it.  Those customers are also trusting Company X's hardware and  software suppliers, ISP, etc., etc., etc.  If the Company X had some sort  of legal liability towards its customers, then this transitive relationship  would not exist.  But because the customers have no recourse if Company X  screws up, it does.  Back doors have the unfortunate property of being all or nothing.  It's  like leaving your house key under the mat.  If no one knows about it, it's  pretty safe.  If everyone knows about it, it makes your door lock  useless.  Borland certainly belongs in the doghouse for this one.  <> <> <>   ** *** ***** ******* *********** *************           The Doghouse: NASA and eTrue    NASA is testing a biometric authentication system that works over the  Internet.  I've repeatedly written, both in these pages and in _Secrets and  Lies_, about the dangers and insecurities of remote biometric  authentication.  But if that weren't enough, the CEO of the biometric  company eTrue was reported to have said: "And anyone attempting to hack  into a NASA system will have his or her own biometric characteristics  logged and recorded."  Why would anyone attempting to break into a network  send his *own* fingerprint to be authenticated?  (Note that it is not a  direct quote in the article, which may mean that the reporter is to blame  for this.)  <>  My essay on biometrics: <>   ** *** ***** ******* *********** *************             A Semantic Attack on URLs    This is clever.  Last month I received an e-mail that said:  Check out breaking news at CNN: < email address is being protected from spambots. You need JavaScript enabled to view it./evarady/www/top_story.htm>  (Unfortunately, the URL no longer works.  But stick with me.)  At first  glance, this looks like a CNN URL.  But the URL does not lead to, or does  not redirect from,  The page is not CNN's.  The URL is a clever  hack that plays with people's assumptions about what a URL is supposed to  look like.  Here's how it works.  An MIT student created a fake Web page and put it up  on his Web site at:  <>  He then sent out the first URL above.  If you examine that URL carefully,  you can see that the host name is not "" but "," which  is the same as  (For extra obfuscation, he  could have converted that host name to decimal.)  That entire bit before  the @-sign -- "" -- is a "username,"  something allowed by the HTTP specification but rarely used in actual URLs.  This is a really clever example of a semantic attack: one that targets  people and meaning rather than computer syntax.  The attacks are obvious:  someone could send a fake e-mail from, telling them to  click on this URL for a free gift.  The URL would look like it came from  the Whatever company, but would instead go to a look-alike site that  harvests the usernames and passwords.  Most Internet users have no idea what a URL is supposed to look like, let  alone how to parse one.  In a world where there is no real way to validate  anything, the URL has become the means that people use to determine the  source of a Web page.  (Does anyone EVER examine a public-key  certificate?)  But if URLs can play with our expectations of what they  should look like, what can we do?  Semantic Attacks: <>   ** *** ***** ******* *********** *************               E-Mail Filter Idiocy    As long as we're mentioning semantic attacks, let's talk about semantic  defenses.  Many companies filter incoming e-mail for viruses, Trojans,  spam, etc.  Some of these filters blocked the January Crypto-Gram.  Ten copies were blocked because they contained the character string  "ILOVEYOU" -- even though they were plain text with no attachments.  This  makes no sense to me:  it's laughably easy to change ILOVEYOU to use some  other subject line, but good luck getting it to spread through plain text  e-mail.  (I suppose you could put the source code in the message and just  hope the recipient would compile it.)  So what the filter really does is  block e-mail containing information about the Trojan, not to mention this  issue of Crypto-Gram.  But that bit of overreaction pales in comparison to this bounce message I  received:  "MailMarshal (an automated content monitoring gateway) has  stopped the following e-mail for the following reason:  It believes it may  contain unacceptable language terms, or inappropriate material....  "MailMarshal Rule: Inbound Messages: Block Unacceptable Language, Script  Profanity Porn and Racism Triggered, Expression: blow AND job Triggered 1  times weighting 5.  For more information on e-mail virus scanning, security  and content management, visit"  That's right, MailMarshal blocked Crypto-Gram because in one place I used  the word "blow" and then a couple of thousand words later I used the word  "job."  And the sad thing is that the very same e-mail filter will block  this issue of Crypto-Gram for the very same reason, and the recipient will  never know.   ** *** ***** ******* *********** *************                       Air Gaps    Whale Communications has been marketing something called e-Gap, which they  claim is an "air gap" between two networks.  Basically, the system consists  of two servers.  One is connected to the Internet and the other to the  internal network.  The two servers only connect through the e-Gap system, a  SCSI-based memory device that gets toggled between them.  The two servers  are never directly connected.  This is an interesting idea, but it's not an air gap.  What E-Gap really does is create a proxy connection between two  computers.  It's a slow connection.  It's a very limited connection; the  system strips down any network layers under the session layer.  What that  means is that if you set up a system using E-Gap and an intruder were to  break into the Internet server, he could not obtain TCP/IP connectivity to  the internal server.  This certainly increases the security of the back-end  server.  Nonetheless, the intruder can still access the back-end server as a regular  client.  The intruder can still break into the internal system by  exploiting any vulnerabilities above the transport layer.  The whole point of an air gap is that there is no automated connection  between the two devices.  It's not simply that there is no physical  connection between the devices most of the time, but that any logical  connection between the two devices is not automated.  If the Internet  server and the back-end server were on opposite sides of a room, there  would be an air gap between them.  To connect the two computers, a user has  to walk a floppy disk across the room.  For an attacker to attack one  computer from the other, he needs to be physically present.  Even if an  attacker gains access to the Internet server remotely, he cannot bridge the  air gap to the back-end server.  While E-Gap can claim that with their device systems are "completely  disconnected at all times," the truth is that their switch operates  automatically at all times.  There is always a logical connection between  the systems connected by their device.  And that connection is subject to  remote attack, and possible compromise.  I'm not saying that this is a bad product -- it sounds like a good product  -- but it is not an air gap.  Calling it one is deceptive marketing.  Kind  of like calling a stream cipher a one-time pad.   Whale's page describing their technology: <> They call it "impenetrable."  Also note that on their home page they don't  just call it an air gap but a *physical* air gap, just in case someone  might have wanted to give them the benefit of the doubt.  A response to critics by someone with Whale: <>  Hall of shame puff piece: <>  Whale isn't the only one.  Here's a review of six "air gap" products: <>  Airgap Networks, which has few details on their product, is notable for  actually defining "air gap" (albeit in an Orwellian manner). <>   ** *** ***** ******* *********** *************     Internet Voting vs. Large-Value e-Commerce    One of the odder comments I've heard in the debate on Internet voting is  the following: "If we can protect multi-billion-dollar e-commerce  transactions on the Internet, certainly we can protect elections" (or words  to that effect).  I've heard it so often that I feel the need to explain  why it isn't true.  There are two important differences between large financial transactions  and voting that make the former much more suitable for networked  implementation: anonymity and recovery.  In _Secrets and Lies_, I made the point that electronic financial systems  based on identity (electronic credit cards, electronic checks, PayPal,  etc.) are much more likely to be implemented than electronic cash because  the former is much easier to secure.  Large financial transactions all have  names attached: who gets the money, who loses the money.  Votes only have  the names of the recipients attached; the whole point of a secret ballot is  to remove the name of the voter.  This makes is much harder to protect the  system from fraud, much harder to detect fraud if it happens, and much  harder to identify the perpetrator and arrest him.  Another difference between large financial transactions and voting is that  you can unwind a financial transaction.  This is important.  If someone  manages to steal a billion dollars from a financial system, you can freeze  the transaction, try to figure out what happened, and hopefully return the  money.  If someone manages to hack the vote, there's nothing you can  do.  This is the lesson from Florida: even in the face of a confusing  ballot, manipulation of absentee ballot applications, widespread voter  irregularities, and voting technology that disproportionally  disenfranchised minorities, there was nothing that could be done.  The vote  was taken on Election Day, and that's that.  Revoting would have been even  more unfair, because it is impossible to recreate the conditions at the  time of the original vote.  Our voting system doesn't allow for the same  ability to redo transactions that our financial systems do.  There's another, less important, difference between large financial  transactions and voting: in the latter, appearances matter.  If someone  claims to have stolen a billion dollars and no one seems to have lost it,  you can safely ignore his boast.  On the other hand, if some political  group claims, on election night, to have hacked the vote...what do you  do?  You can't disprove the claim.  You can't redo the vote to make sure it  is accurate.  Building a secure Internet-based voting system is a very hard problem,  harder than all the other computer security problems we've attempted and  failed at.  I believe that the risks to democracy are too great to attempt it.  Quotes:  Phil Noble, director of, said "...if the largest banks  in the world transfer billions of dollars every day electronically we can  use the same technology to ensure secure voting." <>   From "Analysis of Internet Voting Protocols," by Andre M. Chernay:  "Currently existing software is adequate to protect the integrity of the  ballot once the ballot gets into the Internet pipeline.  Transactions  currently performed over the Internet include e-commerce, the transferring  of funds around the world, and the purchasing and selling of stocks.  For  example, 100 million Americans will go online this year and spend almost  $12 billion in online purchases." <>  This same argument was made on an All Things Considered radio segment  "Allow People to Register to Vote Online" on 10 Aug 1999. <>  "'Vote Integrity on the Internet Is No Different From Billion Dollar  Transactions,' Says Chris Kenber, President and CEO of Hifn." <>   From an article called "About (tele)democracy":  "First, we experience  voter fraud now and always have lived with it.  Today claims about voting  irregularities are heard at nearly every election.  Second, if there is an  incentive to commit electronic fraud, surely money is the prime  motivation.  Yet, every day, hundreds of billions of dollars move through  the banking system with good security.  Fraud exists, but it has been  policed and prosecuted." <>   ** *** ***** ******* *********** *************               Comments from Readers    From: Richard <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Underwriters Laboratories  I used to work for a company that manufactured electric hospital beds, and  was the liaison to UL, and I became very familiar with their modus operandi  and know how the public can continue to be hoodwinked.  First, they take no legal responsibility for a product (if it should fail),  by saying that the product is "Listed" not "Approved".  Listing simply  means that the product met some minimal standards that were in effect at  the time the product was made.  For encryption software, cracking simply  means that that version met the old standard, and the software company  needs to submit a new version to meet the new standard.  Next, they require the manufacturer to pay an annual fee to keep up the  listing, along with allowing a UL inspector to visit the premises and check  various samples periodically.  The manufacturer naturally paid extra for  this.  If the manufacturer wanted to make changes to a product in a listed  area, they had to submit the change beforehand and when UL accepts it  (charging extra, of course), then the manufacturer could put it into  production.  If the inspector found an unauthorized change in the product,  he could tell the manufacturer they could not ship any more product with  the UL label on it.  Since the UL logo is usually part of the regularly  applied product packaging, he was, in effect, halting production.  This  means that if a software company wanted to improve or fix a bug in their  product, they couldn't sell it until UL was satisfied.  Finally, every electrically savvy buyer of electrical products can look at  the guts of a product and pretty well tell if it is reasonably "safe".  The  consumer, on the other hand, is made to believe that the product is totally  safe.  The truth is, is that UL goes through an evolution rating a product  and making changes, just like any manufacturer, and makes mistakes and  fixes to their standards.  So any defect in any given UL Listed Encryption  software would simply mean revisions to their standards.  All of this means money for UL, with no responsibility for any damage done.  Your last paragraph on "Ethical Extortionist" hits the nail exactly on the  head.  It plays right into the current public thinking that we need some  "authority" to validate every facet of our lives.  Authority is one of the  six principles of influence as explained by Dr Robert Cialdini's article on influence.  I guess what I am trying to point out is that while you and I know that UL  is a farce, they will probably be involved and come out smelling like a  rose.  The only way for them not to be involved is if all the encryption  companies band together and ignore them.  But that "authority" stamp of  approval, excuse me, listing is too much of a selling point to be ignored.   From: Nick Rozanski <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: The "Insurance" Model of Security  When most of us think about security, we view it as a binary quality of a  system -- so we ask questions like "Is this system secure?"  The correct  answer to this question is always "no" --­ *any* security architecture can  be broken if there is someone willing to invest the effort, time, and/or  money to break it.  However this approach is flawed.  A much better way is to recognise that it  is impossible to implement totally foolproof security -- the best we can do  is to decide how *resistant to attack* our security architecture needs to  be, which we can do this by answering two questions.  Firstly, "what is the  cost to me if my security architecture is compromised?" And secondly (not  always the same thing) "what is the benefit to someone else of compromising  my security?"  It is important to understand that the answers to these questions come from  the business, not from technologists.  (All we have to do is to design and  build it!) Furthermore, in an ideal world it should be possible to  objectively *demonstrate* that the system provides the required level of  security -- in the same way that we are expected to demonstrate conformance  to other classes of requirement (functional, performance, etc.) as part of  acceptance.  Where we are today, this is very hard, not least because of the difficulty  in quantifying, or better still eliminating, the human factors which so  often seem to be involved in security breaches.  In practice, demonstration  of conformance to security requirements (or otherwise!) usually takes place  after systems go live.  The final question to ask is "how will I respond if (when) my security  architecture is eventually breached?"  This is a problem which needs to be  addressed by both sides -- technology to "tighten up" the security holes  which have been exposed, and business to deal with the commercial fall-out  and make the needed organisational changes.  The answers to these questions  should form part of any security model as much as the technology components do.   From: Greg Guerin <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: On "Code Signing in Microsoft Windows"  Here's a relatively simple attack on the code-signing in Whistler,  regardless of who controls it or what it turns out to be.  1) Create an individual Web-based e-mail account on Hotmail, representing  yourself as a sole proprietorship software developer.  For the truly  criminal, falsify all the information.  2) Register as a developer with Microsoft, providing the Hotmail e-mail  address.  The basic Microsoft registration is probably free.  3) Buy a genuine Authenticode code-signing key.  This may be a non-trivial  expense though probably not more than a few hundred bucks.  For the truly  criminal, pay for it with a stolen credit-card number.  4) Once you have the code-signing certificate, sign your malware with it,  then distribute in the usual way.  If your malware subtly sabotages the  code-signing system itself, say by subverting the root key, so much the better.  5) Make the private key widely public by posting the private key and the  code-signing certificate on a H4KOR 51TE, or by other means.  One truly  wicked possibility is to incorporate the private key and the cert itself as  part of the malware, creating a self-signing worm.  6) Don't tell Microsoft, or the certificate provider, or anyone else that  your private key has been "compromised."  For the truly criminal, delete or  abandon the falsified identity.  Eventually your code-signing certificate will be revoked (we hope).  Until  that happens and the Certificate Revocation List eventually gets around,  your malware can go anywhere and do anything.  It is, after all, completely  authentic and trusted as far as the code-signing process is concerned.  And  if there's no CRL at all, then your malware can survive until its  certificate expires or an antidote is released.  There is some monetary cost involved in this attack, but if a group of even  petty criminals pools their cash, it's basically pocket-change.  And if  they profit from the attacks in some way, then they can create identities  and buy keys on the fly, staying ahead of the CRL effectively forever.  This attack shows what happens when one of the main premises inherent in  the crypto-system is flagrantly violated.  In this case, the intentional  widespread dissemination of the private key makes everything else in the  system, including accountability, moot.   From: Phil Pennock <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: On "Code Signing in Microsoft Windows"  There's another way to defeat this.  If a program is signed and running,  then it's henceforth trusted.  If there's a buffer overrun allowing someone  to smash the stack, then their code is presumably trusted  --  how would  Microsoft prevent it?  Stackguard-like technologies go some way towards  preventing the more trivial attacks, but that's it.  So you have a buffer overrun in, say, an e-mail client.  Given Microsoft's  history, it isn't far-fetched to suppose that it's the default client which  Microsoft ships (but then, the same can be said for c-client).  The lack of  adequate bounds-checking is discovered, someone writes a worm which goes  around, lugging extra code as needed (e.g., along the lines of Samhain) and  they disable the checking on the system.  Hey presto ...   From: Leonardo Humberto Liporati <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Brazilian Voting Machine  The description of the modified PC used in the Brazilian elections has an  error.  The machine doesn't have a small ballot box attached to it.  So the  machine doesn't print and slip every vote into the ballot box.  At the end  of voting the machine only prints some copies of a final report with totals  by candidate.  This is most criticized "weakness" of the machine; there is  no way to recount the votes because there are no physical proof of the  vote, just a digital record on a floppy and in an internal flash memory  card.  This way the machine fails to achieve the AUDIT attribute, enforced  by the fact that the modified PC runs a proprietary operating  system/software whose source code is a commercial secret and can't be  reviewed.  Also the machine is said to use classified encryption  software/algorithm developed by ABIN (the Brazilian secret service) that  isn't available to public review.  This way, when the machine print the  initial "zero votes" report, no one can be sure that it represents the  "initial state," just that the software inside it knows how to print such  report.  There is no way to check/ensure whether the final report (or the  floppy contents) are the real results or pre-programmed values set by the  own government.  The machine also fails to achieve the ANONYMITY attribute.  The machine  holds the name and ID number of each voter of that electoral zone.  Before  every vote, using the remote control, the operator types the ID number of  the voter to release the keypad.  As the software is secret, we can't be  sure that it doesn't record the vote along with the ID of the  voter.  Another problem is that the machine sounds a beep for every key  pressed.  Usually a vote is made by typing the candidate's number (2 to 5  digits) and pressing the "confirm" key, but there is one key for "blank  vote."  So counting the number of beeps we can easy identify blank votes.  The Brazilian electronic system is far from perfect and receives many  criticisms by specialists.  The Web site <> holds  a discussion group about it, but it is in Portuguese.   From: Celso Brites <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Brazilian Voting System  In your Cryptogram December 15 proposal for an automated voting system you  say: "The voter checks the paper ballot for accuracy, and then drops it  into a sealed ballot box.  The paper ballots are the 'official' votes and  can be used for recounts, and the computer provides a quick initial tally."  The paper ballot you propose was used in the first Brazilian electronic  election.  However, it has been abandoned on the elections that followed,  in order to avoid an old type of electoral fraud, known in Brazil as "Voto  de Cabresto" (literally translated, "halter vote").  In this fraud, a  politician (typically a small-town, large property owner) "buys" votes from  his (usually desperately poor) electorate with promises of small benefits,  goods, or even cash.  To assure that they will vote as promised, the  politician uses the following trick: someone in his payroll gets to be the  first one to vote, but it drops any piece of paper instead of his ballot in  the box.  He takes the ballot with him and marks it with a small  handwritten sign.  He then hands it to the first of the politician  "clients", which is instructed to put the signed ballot in the box and  bring his own ballot back, thus proving he voted for the "right"  candidate.  The whole process is then repeated: the new ballot is signed  and handed to the next "client".  This process could be avoided by using a sealed transparent conduit between  the machine and the box, so that the voter would not touch the ballot, but  could check if it was properly printed. For some reason it was not adopted.   From: Todd Hooper <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Publishing Security Advisories  I think the spat between Microsoft and Bugtraq is less about the rights of  the security community, and more about Bugtraq (aka SecurityFocus)  protecting their income stream from advertising on their portal.  If  Microsoft don't let them distribute the material, the value of Bugtraq (and  SecurityFocus) is reduced in some fashion.   From: Jonah Duckles <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Gianus in the Doghouse  I found your "Doghouse" entry for <> intriguing.  I  visited their site and found that they were claiming they had full  technical reports detailing how none of the independent testing agencies  they had submitted their product to were able to access protected  information.  The two "technical" reports that I received had descriptions  that basically were accounts of how good the product seemed to be.  There  was no technical probing of what kinds of things the product was actually  doing to "hide" the data.  I contacted the person who had sent me these technical reports again to say  that I felt the product simply obfuscates the data and does not actually  provide any security and I received the following e-mail:        From: "GIANUS TECHNOLOGIES" <This email address is being protected from spambots. You need JavaScript enabled to view it.>       To: "Jonah Duckles" <This email address is being protected from spambots. You need JavaScript enabled to view it.>       Subject: RE: Technical Reviews       Date: Wed, 24 Jan 2001 13:15:29 -0800        So, Mr. Duckles, maybe you're the genius we were looking for!!!        How can you express an opinion about something you have never even seen??        You are more than welcome to try to retrieve any information we protect       with the Phantom. ...But what do we get if you cannot???        There probably is a reason why you are in the academic world, and not in       the commercial (real) one.        Best Regards.       ____________________________________________       GIANUS TECHNOLOGIES  I guess you have every reason to keep these guys out in the Doghouse, for  bad security practice AND bad PR.   ** *** ***** ******* *********** *************  CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,  insights, and commentaries on computer security and cryptography.  To subscribe, visit <> or send a  blank message to This email address is being protected from spambots. You need JavaScript enabled to view it..  To unsubscribe,  visit <>.  Back issues are  available on <>.  Please feel free to forward CRYPTO-GRAM to colleagues and friends who will  find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as  it is reprinted in its entirety.  CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO of  Counterpane Internet Security Inc., the author of _Secrets and Lies_ and  _Applied Cryptography_, and an inventor of the Blowfish, Twofish, and  Yarrow algorithms.  He served on the board of the International Association  for Cryptologic Research, EPIC, and VTW.  He is a frequent writer and  lecturer on computer security and cryptography.  Counterpane Internet Security, Inc. is a venture-funded company bringing  innovative managed security solutions to the enterprise.  <>  Copyright (c) 2001 by Counterpane Internet Security, Inc. 
    You are not authorised to post comments.

    LinuxSecurity Poll

    Do you reuse passwords across multiple accounts?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 2 answer(s).


    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.