Fairhaven, The River

Encrypted Disks

The May CACM has an article on recovering passwords from RAM and using that to break protection on encrypted hard disks.  It remains crucial to decide what risks you have and what the real threat is.  DICOM just approved the standards for using password protection on removable media.  (It already had PKI based encryption covered, but in practice the password based in far more usable.  With suitable precautions it is probably just as robust against the real threats.)  It protects reasonably well against exposure through media theft, but only with the assumption that the passphrase is well protected.  If you write the passphrase on the media, you eliminate most of the protections.

My risk analysis based on their work is this:

1. If you are personally a target, all current disk encryption methods will be breached.  You might be a personal target through criminal activity, military activity, political activity, etc.  Disk encryption is not protection for you.
2. If you are a target of opportunity, disk encryption alone can be breached.  Actually, some techniques like the default TPM and basic Bitlocker of Vista reduce your protection because they fool you into thinking that you are protected, while in fact you are not.  Most people are a target of opportunity.  If a thief steals your laptop and thinks - "I wonder if there are any worthwhile secrets on this thing?" you just became a target.
3. If you are worried about parts depot repair, recycling, re-sale, etc. then current disk encryption is usually good protection.  Just make sure to shut down a few hours before handing over the system, or make sure that they remove the disk and are not left alone to play with the system.  Of course erasing the disk is even better if you know that the disk will be sold or re-used.

The problem is that at room temperature the RAM bits take too long to zero.  There is ample time for someone to reboot the system using either USB boot or PXE boot and copy out the contents of RAM.  You need to be power off for 30+ minutes before there is much confidence that data will not be recoverable.  They did the proof by implementation that automated RAM scanners can find passwords and break in to all of the popular open source and proprietary disk encryption systems.  The keys are right there.  (If you use TPM and basic Vista bitlocker, you can have power off forever and still get the keys.  The keys are in non-volatile RAM.  Bitlocker users should use one of the more advanced modes.  Microsoft should remove the basic mode.)

In practice there is also the extremely serious problem that laptops are basically left on all the time, although for power reasons they may be in standby or hibernate modes.  This is because it takes too long to boot, and it takes too long to restore user context.   One of the reasons that I and others like the Mac is that you can just close the lid and it goes to sleep within seconds (and nothing breaks).  You can restore operation by opening the lid, and again it is ready within seconds.   You can configure it to ask for a password, but the keys are not scrubbed from memory, so a sleeping system can be stolen and keys retrieved.

If boot were really fast (through techniques like saved context information on disk), the memory (or at least keys)  scrubbed on sleep/shutdown, then systems might be somewhat secure.

Something to think about when protecting information from opportunistic theft.

Two cheers for Apple

I'm somewhat disabled by the temporary loss of use of my MacBook, but Apple does do a good job for their customers.  When the battery failed a few months ago the replacement took under a minute.  It was a simple "Still covered by extended care? Yes.  Here's your new battery."   Too many retailers still bury you in paperwork and questions.

Now it suffered an LCD failure.  (Ugly blotches appeared on the screen.)  The "genius" took a quick look at it, said "It's a hardware problem of some sort.", inventory check showed that it will be a few days getting the replacement, so I've got a receipt rather than a laptop.  Again, no fussy questions or paperwork.  The only downside is the wait for its repair.  (They replace the entire LCD side of the clamshell, and didn't have the glossy screens in stock.)

The advice to buy extended care with their laptop is very good. 

WS-splat

We had to take a sad step today.  We enabled the use of hash codes and hash code checking on transactions that are sent using WS-*.  It seems that the implementations remain too unstable and do not reliably handle large data transfer.  It's just bugs, but we shouldn't be seeing bugs at this stage.

One reason DICOM succeeded

DICOM is now a highly successful standard, and I occasionally think about why this is.  I was first involved in 1991, and have been involved on and off ever since.  It is different from most standards in that participants tend to be highly pragmatic, and willing to compromise for the sake of making things work.  I think that this is part of why it has succeeded.

One reason for this pragmatism is the original forcing function for DICOM.  In the late 1980's and early 1990's hospitals were "owned" by the MR vendor.  Each vendor had its own proprietary networking system for imaging systems.   The MR system was the really big ticket purchase for a hospital.  So the effect was that a hospital with a GE MR system would have GE for all the rest.  A Siemens MR owner would have Siemens for all the rest.  And this was a tremendous problem for the hospitals.  They wanted to be able to buy from a variety of vendors without suffering from network problems.

They laid down a nuclear threat.  They threatened to disqualify any product that did not interoperate with imaging equipment from other vendors.  The threat was to officially label that product as not suitable for medical use.  The NEMA standard that preceded DICOM had failed to be widely accepted (for a variety of good reasons) but there was a lot learned from attempts to use it.  It was clear that a standard was needed in order to accomplish interoperability.

But this is different from most standards processes.  The goal was not creation of a standard.  We were going to be put out of business if our products did not interoperate.  The standard was merely a step on the road toward that goal.  Most of us involved with creating the standard were engineering managers or product managers.  We would be failures if all we did was write a standard.  Success required product integration and successful interoperation with products from other vendors.   The standards consultants, standards experts, and the like were not welcome unless they contributed toward our success.

This did establish a tradition of pragmatism.  Making the system work was far more important than following any particular theory or standards practice.  Academic and theoretical purity was of value only to the extent that it helped ensure that things worked when we were done.  The "fad du jure" (e.g., SOA) was unwelcome.  We had products with long lifespans, strict regulatory requirements, and tight pricing pressures.   Technology fads had no influence on medical buyers.  They were influenced by medical fads.  So, as engineering and product managers who needed to sell products we stomped out the technology fads, unless they could show pragmatic value as enhancing our chances of success.

This is very different from many SDOs.   In many SDOs the development team reaches their goal with the successful balloting of the standard.  That is the target.  That is what they get paid for.  We knew that we were not done until we had a cost effective implementation of the standard, working in our product, selling to our customers, and acceptably interoperating with the other machines on the customers network.  Having this different goal and different staffing made a difference in our practices, attitudes, and traditions.

This is one reason that DICOM succeeded.

Thoughts on standards preparation

I've started considering the use of "git" for the development of standards.  The fit with standards development is good. 

During standards development we have multiple groups are working on supplements and a base standard.  We presently use supplements and CPs as a high level visible organizing principle. These correspond to different bug fix and feature add paths in a config management system (CMS). There are multiple distributed development groups, each needing their own head.  These occasionally interact by spawning changes to another branch.

This is very similar to the environment inside the Linux Kernel and X window system.  Both of those are very large projects that have autonomous development teams and individuals working to generate a single common release.  There are a variety of internal projects that have low interactions with others (e.g., device drivers, 3D rendering, etc.)  These do find and spawn fixes to other projects.  They do have to maintain long-duration multi-release projects while sustaining regular small feature releases and bug fixes.  The end result has to support multiple releases, back ports to earlier releases, and reversions.

So the problem space is very similar.

The core differences between standards development and software development (and these matter a lot to the people involved) are:

• The underlying file formats used by SDOs are hostile to external change management.  Software developers use computer languages that are regular text files.  The languages are designed to maximize change locality.  It is natural to change one line in the language and have only one line of text change in the file body.  SDOs use Word and other formats that are generally hostile to this concept.  They are usually opaque binary blobs.
• The tools used to develop these files are hostile to external change management.  There is no tooling integration with CVS, or any of the commonly available CMS tools.

This is one reason that Wiki's are exploding in popularity for documents.  Although they are a pitiful CMS, they are a tool that does generate a text form underlying object.  They remain mostly hostile to external change management.  For example, the mediawiki tool that is behind Wikipedia, IHE wiki, and many others, does not support easy export and import of the underlying text files.  For example, the inability to use wget (or any similar tool) to export or capture contents is a bug that was recognized and listed several years ago.  It remains on the not planned (much less scheduled) for a fix or feature add.  The developers acknowledge that they are hostile to external CMS and do not view this as an important problem.

Consider the possibilities opened by the slow moving efforts to move DICOM into an XML format.  The actual format selected is DocBook, so the DICOM in XML should really be renamed DICOM in DocBook.  DocBook is very friendly to external CMS and also friendly to export into multiple forms (PDF, DOC, HTML, SGML, Wiki).  Unfortunately, DocBook lacks usable GUI writing tools.

The lack of usable GUI writing tools has been a profound barrier to the acceptance of DocBook.  The writers will not use it.  Only the occasional odd-ball writer will tolerate DocBook.

Internet and Air Travel Efficiency

There's an MIT paper that argues that the recent shift of airline load factor up from around 0.75 to 0.85 is due to the Internet effect.  With the addition of computer advice on available flights from multiple airlines and the trend to more direct personal selection of flights, the airlines are able to fill more seats.  It argues that the extensive Internet access by the public was a necessary part of the change.  The airline reservation systems tools plus travel agent seem to have stabilized around 0.75.

As a regular traveler, it is also becoming apparent that as the load factor climbs above 0.90 on more routes, the impact of weather delays and other disruptions is becoming severe.  At 0.90, it takes nine successful flights to recover from one canceled flight.  So there is not much more efficiency to be gained by ticketing.

The next major gains will have to come from traffic route revisions and from replacement of aircraft with more efficient aircraft.  The next planned traffic revision is RND routing around airports (which makes a noticable improvement in fuel use by allowing continuous curved ascents and descents instead of the fixed level straight line routes in widespread current use).  RND routing requires a significant investment in route planning and facility upgrades to prepare the air traffic control for that airport.  It also requires upgrades to many aircraft.  It's now very common in Alaska, where terrain restrictions and weather made it much more important.  It is being phased in on an airport by airport basis in the lower 48.

After that, there is also the potential for improvements by replacing more hub and spoke traffic with direct traffic.  This is a

GPRS for my Mac

I've used my T-Mobile GPRS service as the backup for the corporate laptop for a couple years now.  The instructions for that were clear.  I just today got it working on my Mac Laptop.  The key is the modem scripts and configuration information at Barkman's GPRS page.  I had found the scripts when I first got the laptop, but the instructions were missing.   I couldn't get it to work.  Now that there is the nice big table of configuration parameters and better instructions, I got it working on the first try.

This is very useful so Barkman deserves the google love of a reference.

I also like the T-mobile service for it's low price.  I can usually find WiFi, so I don't want to spend a lot of money for broadband.  This service costs only $30/mo, seems to be genuinely unlimited use, and the lower speed is good enough for email sync and lightweight browsing.   But the T-mobile web site and help desk were completely useless and unable to help configure a Mac.

Why digital signatures don't work

At Tuesday's town planning committee meeting we had one applicant for a parking waiver.  He made a quick presentation showing how they planned to add another office space to a warehouse and add a couple parking places for it.  This just involved putting marks on the warehouse driveway.  It doesn't require a zoning change.  It's just a change to the registered building plan.

The chair asked the consulting engineer for his report.  He listed changes A, B, C, ... and G between the plans he was given and the new plan.  Two board promptly started talking about changes B and C.  They had a bunch of doubts and questions.  The applicant answered some questions and dug through his documents.

As the two board members got going he put up another plot plan and asked:  "Why are we talking about this again?  You agreed to this back in November.  See, here are your signatures on the approved plan.  It shows those changes."

The consulting engineer said he had been given plans dated July for comparison.  A quick look and he agreed that the only change between the signed November plan and the proposed plan was the office space layout and parking places.  The two board members walked up, saw their signatures, and sat back down.

The office space and parking change was agreed to be minor and the new plans approved.

Signatures exist in large part to make board members and applicants shut up and sit down. 

This works for several reasons. 

First, there is a signing ceremony.  This ceremony involves ritual motions, ritual words, public observation, and sometimes other steps.  The ceremony is a recognized and understood end point.  It ends social acceptance your ability to make changes.  It is important that the the ritual motions be unique.  A physical signature is a ritual motion that you almost never use for any other purpose.  It is not just an emotional or intellectual difference.  The physical movements are unique, non-trivial, and not accidental.  You must use muscles and eyes to perform it properly.  It leaves behind a physical artifact that you personally recognize.

Similarly, the witnesses are physically there and can observe and confirm this ritual motion.  After a while, they also have the ability to immediately recognize the resulting physical artifact.

For plot plans there is more to the ritual.  Not only are there the signatures of the board, this is preceded by stamping the plot pages with the official stamp, the signatures are on the stamp, and after the signatures are there the paper is sealed with a press that bends, dents, and selectively tears the paper that was stamped.  All of this is something that can be recognized and confirmed by those present.

Second, the board members immediately recognized the physical results of that ceremony and recognized the social power.  They shut up.  This was not some arguable computer magic.  They were able to perform their own immediate verification.

Perhaps some day the digital signature will reach the level that these physical signatures have reached.  There will be the ceremony that ensures that all the participants recognize that they are agreeing to an endpoint.  Pushing a button on a computer is not a unique ceremony with witnesses.  It is not a unique motion used for no other purpose.  A whole ceremony process needs to be invented for the digital signature that it presently lacks.

Issues of ceremony, social witnessing, etc. are malleable.  Ceremonies change.  So the digital signature can reach general acceptance, but the endless fascination with esoteric internal implementation details is not creating a proper ceremonial process.  In fact, the current user interfaces for computers make it quite a large challenge to create a proper family of ceremonies.  Physical signature ceremonies are rather adaptable and cover the range from the quick initialling in a hurry to the formal multiparty signing ceremony with stamps and seals that is used for building plan approvals.  Digital signing ceremonies will need to provide that same spectrum of ceremony.

The validation of signatures is similarly immature.  There is no technological barrier to the quick verification of physical signatures.  Those two board members took less than a second to confirm their own signatures.  They could have argued forgery.  Forgery is unlikely because of the high cost of creating the forgery and the near certainty that it would be discovered because other duplicate copies of the plans are kept in storage at various locations.  A successful forgery would need to substitute those also.  Getting approval for an office and some parking does not justify all that expense and risk.

Digital verification might reach that same degree of universality some day, but it will take decades or centuries.  It's not just a matter of computer access.  What the board members were verifying was that the plans that they saw had been signed.  If a computer were involved you must figure out how to ensure that the photons emitted correspond to the digital signatures.  The relationship between photons and signatures is inherent in the physical processes of paper and light.  If this were a plan being projected by a computer, how do I know that the digital signature corresponds to the projection?  If I do not trust the presenter, why trust the projection.  This means that I need the document to be provided to me so that I can use a computer and projection system that I trust.  Lack of trust can go both ways, so this comparison of photons can become very difficult logistically.  Every participant must have their own trusted viewing system and verification system.  It's a rather huge investment in equipment and facilities to reach the point where everyone has this and can confirm signatures to their own satisfaction in less than a second.

For now, that piece of paper and those physical signatures are meeting the signature goal.  The investment in physical resources and new scial ceremonies will not happen just to improve signatures.  The improvement is not that valuable.  It will happen when other reasons and purposes have justified the investment in computers, etc.  Then social ceremonies can be created and digital signatures finally become practical.  (Assuming that something better has not been invented first.)

Multi-chip technologies

There are more interesting was emerging to reduce power use while meeting common processing needs for commercial aps. The multi-core/ multi-thread CPUs are emerging strongly. There was the recent Sun multi-core, which offers 96 execution threads on a 60W CPU. It's using multiple threads on multiple cores. It presents a sort of single CPU appearance. Then there is the just announced mesh multi-core. It exposes a grid architecture that is a much faster version of the grids that are already supported by the various grid software approaches.

All of these are improving the speed of the multi-thread paradigm, rather than the speed of individual threads. In fact, the individual threads are often much slower than an ordinary PC. It has taken a long time for software technology to reach the point where multi-threaded solutions are really useful. I recall just how difficult it was to make things work in the early days (1980's) when I worked on it. The underlying software support was not ready for hard problems.

OpenSuse 10.2 Review

I just got finished installing OpenSuSE 10.2 on my Linux workstation. It had been at 10.0. Overall, it is very painless. It's a lot easier than installing Windows.

The motivator was multi-fold. First, there was the DST patch. I could have just fixed the tz file, but it has been a while since I did a general upgrade and that gave me a motivating date. So finally, I downloaded the Open DVD, burned the DVD on my windows system, copied all 40GB of stuff over to another disk, rebuild, and restored 40GB. This took about a week since it had to be done in my free time (which has been very limited).

Pretty much everything worked. All sorts of little things have been fixed. For example, my HP Photosmart printer support is now supported properly by OpenSuSE instead of having to be manually downloaded and installed by me. There were only two minor problems:

1) The Canon i9100 support was a trickier install. I need the Canon for the ledger size printing. Canon will not disclose details for open source drivers, so I purchased the Linux driver from turboprint. It's install is a tiny bit incompatible. I found that what you need to do is install the turboprint software, install the license, but do not use it to create the printer queues. Instead, use YAST2 to set up the queues. YAST2 recognizes the new capabilities once the turboprint software is installed and creates printer queues properly. (There must be some oddity about file locations, or the like.)

2) The default automounting for the iPod is not right. I need to fix that. Right now it is getting mounted usable by root only. But gtkpod now deals with it just fine out of the DVD with no tweaking needed by me.

The other key to a good transition is having all the configuration files, mail directories, etc. over in your home directory, create a new user with the same uid, and restore the old stuff. I didn't lose anything this time.