Day: September 18, 2005

Richard Bejtlich has captured a lot about the kinds of concerns which motivate me to do this blog, and which lay behind my work on the Laws of Identity, in this piece from TaoSecurity.

‘I watched an episode of Modern Marvels on the History Channel this afternoon. It was Engineering Disasters 11, one in a series of videos on engineering failures. A few thoughts came to mind while watching the show. I will provide commentary on each topic addressed by the episode.

• ‘First discussed was the 1944 Cleveland liquified natural gas (LNG) fire. Engineers built a new LNG tank out of material that failed when exposed to cold, torching nearby homes and businesses when ignited. 128 people died. Engineers were not aware of the metal's failure properties, and absolutely no defensive measures were in place around the tank to protect civilian infrastructure.

  ‘This disaster revealed the need to (1) implement plans and defenses to contain catastrophe, (2) monitor to detect problems and warn potential victims, and (3) thoroughly test designs against possible environmental conditions prior to implementation. These days LNG tanks are surrounded by berms capable of containing a complete spill, and they are closely monitored for problems. Homes and businesses are also located far away from the tanks.

• ‘Next came the 1981 Kansas City Hyatt walkway collapse that killed 114 people. A construction change resulted in an incredibly weak implementation that failed under load. Cost was not to blame; a part that might have prevented failure cost less than $1. Instead, lack of oversight, poor accountability, broken processes, a rushed build, and compromise of the original design resulted in disaster. This case introduced me to the term “structural engineer of record,” a person who assigns a seal to the plans used to construct a building. The two engineers of record for the Hyatt plans lost their licenses.

  ‘I wonder what would happen if network architectures were stamped by “security engineers of record?” If they were not willing to afix their stamp, that would indicate problems they could not tolerate. If they are willing to stamp a plan, and massive failure from poor design occurs, the engineer should be fired.

• ‘The third event was a massive sink hole in 1993 in an Atlanta Marriott hotel parking lot. A sewer drain originally built above ground decades earlier was buried 40 feet under the parking lot. A so-called “safety net” built under the parking lot was supposed to provide additional security by giving hotel owners time to evacuate the premises if a sink hole began to develop.

  ‘Instead, the safety net masked the presence of the sink hole and let it enlarge until it was over 100 feet wide and beyond the net's capacity. Two people standing in the parking lot died when the sewer, sink hole, and net collapsed. This disaster demonstrated the importance of not operating a system (the sewer) outside of its operating design (above ground). The event also showed how products (the net) may introduce a false sense of security and/or unintended consequences.

• ‘Next came the 1931 Yangzi River floods that killed 145,000 people. The floods were the result of extended rain that overcame levees built decades earlier by amateur builders, usually farmers protecting their lands. The Chinese government's relief efforts were hampered by the Japanese invasion and subsequent civil war. This disaster showed the weaknesses of defenses built by amateurs, for which no one is responsible. It also showed how other security incidents can degrade recovery operations.

  ‘Does your organization operate critical infrastructure that someone else built before you arrived? Perhaps it's the DNS server that no one knows how to administer. Maybe its the time service installed on the Windows server that no one touches. What amateur levee is waiting to break in your organization?

• ‘The final disaster revolved around the deadly substance asbestos. The story began by extolling the virtues of asbestos, such as its resistance to heat. This extremely user-friendly feature resulted in asbestos deployments in countless products and locations. In 1924 a 33-year-old, 20-year textile veteran died, and her autopsy provided the first concrete evidence of asbestos’ toxicity. A 1930 British study of textile workers revealed abnormally high numbers of asbestos-related deaths. As early as 1918 insurance companies were relucant to cover textile workers due to their susceptibility to early death. As early as the 1930s the asbestos industry suppressed conclusions in research they sponsored when it revealed asbestos’ harmful effects.

  ‘By 1972, the US Occupational Safety and Health Administration arrived on the scene and chose asbestos as the first substance it would regulate. Still, today there are hundreds of thousands of pending legal cases, but asbestos is not banned in the US. This case demonstrated the importance of properly weighing risks against benefits. The need to independently measure and monitor risks outside of a vendor's promises was also shown.

‘I believe all of these cases can teach us something useful about digital security engineering. The main difference between the first four cases and the digital security world is the failure in the analog world is blatantly obvious. Digital failures can be far more subtle; it may take weeks or months (or years) for secuirty failures to be detected, unlike sink holes in parking lots. The fifth case, describing asbestos, is similar to digital security because harmful effects were not immediately apparent.

Much of our work is intended to correct early initiatives involving identity and identification so we don't end up as the subject matter for some future generation's history of engineering disasters.

Queryable fixed tracking devices when wrongly used can result in death (in the literal sense) as surely as the other disasters outlined above. Designing and massively deploying an infrastructure which is an identity-catastrophe-in-waiting is as irresponsible as the actions of earlier generations of engineers who lacked the doubt and capability for self-criticism and re-examination necessary to be an engineering professional.

This is very much what we were trying to get at when proposing the Laws of Identity.

[tags: Engineering Disasters, The Laws of Identity, Digital Identity]

Britain's David Birch, director of Consult Hyperion, reports on the latest developments in contactless payment systems in an article that appeared recently on Principia. He also reviews the associated security and privacy implications. I recommend you read the whole piece, since it is a thorough look at an important new technology; but here are some morsels to pique your interest:

‘The announcement of schemes such as MasterCard's Paypass, American Express ExpressPay and Visa's contactless initiatives is a sign that contactless smart cards are moving out of mass transit (e.g. London's Oyster card) and into the mass market.

‘Indeed, Datamonitor have forecast that the market for these ‘payment tokens’ will grow at 47 per cent per annum over the next five years. The international payment schemes’ interest is obvious. At a time when it's hard to explain to a consumer why a contact smart card (such as the ‘chip and PIN’ payment cards being deployed around the world) is better than a magnetic stripe card, payment tokens immediately differentiate themselves by offering a completely different (and significantly more convenient) consumer experience.

‘Why? Because the token needs only to be waved close to the terminal. In many cases, it will work fine while still in a bag or briefcase providing it is close enough to the terminal. The distance depends on the type of device used; the type of ‘proximity interface’ chip being discussed in this article will work up to a few centimetres from the terminals…

‘Nokia have said that they think payment tag technology is better than Bluetooth or Infra-red for mobile payments and, in Japan, NTT DoCoMo and Sony have formed a joint venture (FeliCa Networks) to develop a version of the Sony FeliCa contactless chip for embedding into mobile phones and to operate the FeliCa platform for m-commerce. For many consumers, this will be the ultimate in convenience because the phone provides the communications link for managing the payment account as well as the physical payment device. The dreams of the mobile payment community will come true, but not in the way that they thought.

‘Payment tokens

‘So how do payment tokens work to deliver the appropriate levels of both security and privacy? To answer this question, it's necessary to understand how they work. In the general case, the payment token comprises a microprocessor with hardware support for cryptographic operation and an RF interface. There are various standards in this space, but the one most widely used for payment tokens at present is ISO/IEC 14443.

‘In a typical retail environment the retailer's point-of-sale (POS) terminal and the payment token both contain a microprocessor; the microprocessors communicate using a payment protocol (on top of the ISO 14443 protocol for basic data exchange).

‘When it is time to pay, the customer brings their tag close to the POS terminal. The terminal interrogates the card and gets back the serial number and a cryptogram (a one-time code calculated inside the token). It feeds these to the acquiring bank, which passes them back to the issuer. From the serial number, the issuer knows which account to authorise and from the cryptogram the issuer knows that the token is valid.

‘The cryptogram is made up from the serial number and a transaction counter, encrypted using the token security key. This key is inserted in the token during manufacturing; it is derived from the serial number and a bank master key. Once in the token, it is never divulged. This kind of solution provides:

• Privacy, because the token ID is meaningless to anyone other than the issuing bank which can map that ID to an actual account or card number;
• Security, because knowing the token ID is insufficient to create a cloned token. Also, a cloned token would not generate a correct cryptogram because it would not have the right security key and if the transaction is replayed the transaction counter will be wrong.

‘Please note that this is an example given for the purpose of discussion; it is not meant to represent any of the operational schemes discussed in this article. The security of this typical example scheme is not absolute. There is no cardholder verification (i.e. a signature or a PIN), but all transactions are authorised online, so a lost or stolen card can be blocked as soon as it is reported (although it has to be said that consumers will generally notice the loss or their keys or mobile phone pretty quickly). For this example scheme, it might be useful to add an online PIN only for transactions above £20 or so. ‘

The attention to privacy considerations in these scenarios is essential.

How many users of public transit would want to generate a computerized record of every place they have gone, the time of day they have traveled, and how long they have remained there – throughout their lives?

If the use of the tokens generalizes and they become an important method of payment, it becomes easy to combine this information with the rest of an individual's purchasing history, potentially including everything from books and magazines to digital media.

Is it is true you would have to ask the issuing authority about who had purchased the contactless tracking device? I don't think so. What if you had some other way to establish the link between the device and the user's identity? For example, requiring another piece of identification – even once – and using it to perform the association.

So in my view, these scenarios call for a more sophisticated cryptographic approach than that used as an example by David. To be clear, in his very imformative article, he certainly leaves such alternatives open. I can understand that in introducing the technology he didn't want to get diverted into a privacy threat analysis.

There are well known mechanisms for doing everything described here while making it impossible to distinguish one individual device from another unless it is being misused (e.g. has been cloned in an attempt to defraud). Let's use them.

Given problems such as terrorism, there may be some who think a fixed tracking ID could be used to monitor the travel of criminal elements. We should make it clear that this won't work for very long.

Criminals will soon come to understand the need to “cover their tracks”. They will gain access to alternate (fraudulently obtained or freshly stolen) tokens and employ the alternate tokens in endeavors that require secrecy. In this case tokens may actually make it easier for criminals to dissimulate their activities. Only bottom rung vandals, those prone to unpremeditated stupidity, and ordinary citizens can be monitored through this type of technology.

Worse, continuing to promulgate fixed beacon technology is a bit like doling out Cruise missile guidance systems to enemy agents. They allow terrorists and agents of organized crime to mount increasingly accurate surgically directed attacks.

Even if someone could imagine a scenario where fixed-beacon tracking were useful enough to justify the security and privacy problems it causes, there are ways the same high level goals could be met without endangering the privacy of the whole population. For example, it is possible to encrypt the fixed identifier of the device under a key which can only be accessed through a highly controlled process – and include the encrypted identifier in the cryptogram which is otherwise anonymous. This would make it possible, in specific circumstances approved by the courts, to follow individual itineraries, without compromising the privacy of every single user of the system by tying identifiers into mineable records.

[tags: Public Transit, Privacy Threat Analysis, RFID, Contactless Payment, Identity, David Birch]