Security on a PDA is
similar to that on a laptop computer, but carried to extremes. See my document
Cryptographic Vault
for a discussion of laptops and datacenter
security, and for an introduction to the philosophy I'm describing here.
First, what is the paylod that is being threatened? Here are just a few examples of stealable payloads.
The launch codes for some nation's massive arsenal of nuclear missiles. OK, this is megalomanic, but if we're going to make the effort to be secure, we should do the best we can, and by keeping a maximal payload in focus we'll not tolerate half measures.
Account numbers, social security numbers, etc. for 30,000 retirees whose accounts are managed by a major mutual fund company. A laptop with this exact data was stolen recently. Weasel words in press releases suggest that the data was on an encrypted filesystem which may not have been mounted at the time. But the Nokia 770 could hold that database easily on a 1 GB memory card, and I can think of scenarios where there would be a valid business reason to have that table available on a PDA (and if one has an Internet Tablet, alternative ways to serve the data that are not so dangerous).
Il libretto nero del Don Giovanni (the little black book of Don Juan).
Your SSH secret key which gives root access to your datacenter servers. Normally the SSH key is separately encrypted, but for reasonable convenience, e.g. to copy files, you need to load it into the ssh-agent.
The secret key that goes with your X.509 digital certificate(s) that give you access over the web to sensitive work data or which allow financial disbursements. Again it is normally separately encrypted, but generally a web browser will ask for the passphrase once and then remember it for the rest of the session.
As with a laptop computer, the primary threat is theft.
The threat of hacking or viruses cannot be dismissed, particularly if the operating system is Windows® Mobile, but the measures needed to discourage hackers and malware are rather orthogonal to measures taken against theft, and they will be discussed relatively little in this document. See the Cryptovault URL above for a more extensive discussion.
If the thief snatches the PDA out of your hand and starts using it, the PDA has few clues that it needs to clam up -- sense of smell? (A security alembic or leash can help protect against snatches.) Therefore I'm going to focus on the theft of a PDA which is in the standby state or otherwise is not in active use. Here's a sample scenario that the security measures need to resist:
Having lunch at a tony sidewalk café in Basel, a researcher for a multinational pharmaceutical firm is discussing with a co-worker the latest blockbuster drug, using the sketchpad application on his Nokia N810 Internet Tablet (whose screen can be seen in the warm sunlight) to show structural variants and the needed accomodations in the manufacturing process. No sensitive information on napkins this time! The waiter appears with their soup course. Oh, terrible, the soup has spilled all over Monsieur's jacket! Oh, quel catastrophe! (Wipe, wipe.) (Etc. etc.)
By the time the waiter, or his supervisor, can start pawing at the PDA it should have realized that it was not being paid attention to, and it should have gone into standby mode, which should include clamming up. The length of the standby timeout is configurable and on a security-sensitive machine should be kept short. With any competence in the security design, the Sun will turn into a cinder before the competitors get their hands on those sketches. Of course the researcher was violating company security rules by taking his work PDA out of the building, or by even opening his mouth in a public place.
This scenario illustrates another key point in security: it's useless if it isn't used. Here the researcher tried to have a normal life, which is not compatible with high-level security. More relevant to mere mortals, if the users can't get their work done, they won't use the security at all. Not everyone can afford the infrastructure to keep his work and personal life strictly separate, e.g. using the work PDA only within the security perimeter. And there's also the issue of corporate culture: I interpret the Wen Ho Lee escapade at Los Alamos as a serious breakdown of working together to keep the dangerous information safe -- researchers did not take security seriously, while security personnel failed to accomodate the researchers' need for unhindered communication. The security regime on the PDA needs to balance effectiveness and convenience of use, so the user (just me :-) will use it consistently.
Thus, non-use of the security measures has to be counted as a threat.
This design can be summarized easily: Based on a timeout or on a user action (e.g. covering the screen), the PDA enters standby mode. This includes clamming up: secrets are forgotten (e.g. the SSH key agent), and crypto filesystems are unmounted. When the machine wakes up the user will need to give a password to make the clam open.
On the Nokia 770, the deepness of sleep is greater when it's covered than when the screen is blanked after an activity timeout. However, the latter state is the key for the most effective security protection. The N810 does not have a screen cover and does not distinguish levels of sleep as far as I can tell.
Most data on my PDA does not need protection: music files, journal articles, grocery list, blood pressure record... I could use it for quite some time before needing one of my secrets, likely through several sleep-wake cycles. This means that the clam open action should not happen at wakeup time, but rather when one of the secrets is actually accessed.
The technique of the Cryptographic Vault is very applicable to the PDA. Basically, all the secrets are in one (or a few) small crypto filesystems, which on the laptop are mounted when the user logs in, using his password which is provided via PAM. Within the crypto filesystems many of the secrets need to be unencrypted, e.g. the secret key that goes with the X.509 digital certificate which the Postfix mailer uses to send mail to a gateway that requires SMTP authentication (port 587). If feasible, some secrets have a second encryption, mainly the SSH key, so it cannot be stolen by a hacker doing a root exploit. This secret is loaded into the SSH key agent, again at login time using the password saved by PAM.
When the laptop is suspended, secrets are erased and the Crypytographic Vault is unmounted, and the screen is pre-locked. When the machine wakes up the screen locker uses PAM to authenticate the user, and the login scripts are run again to remount the crypto filesystems and reload the SSH key. On my laptop this all works smoothly and unobtrusively. But people without security issues may object to entering their password when waking up their machines.
How can this be adapted for the PDA? Let's first look at an ideal system where I can change anything I want.
PDAs are designed to be used by only one user, as with MS-DOS. There's no need to put on a full multi-user paradigm: at boot time you get ready to use the Cryptographic Vault but you don't open it until actually needed. This means you start ssh-agent but do not load any keys into it.
A userspace linked filesystem based on FUSE is mounted on the mount point(s) of the Cryptographic Vault. If anything reads a file in it, its userspace daemon is coded with enough brains to request the user's password, and it will then mount the crypto filesystem over itself, after which the kernel does all the work. It will also decrypt and load the SSH key. For a more complicated setup there may be several filesystems with different purposes, and the userspace daemon may mount only the requested one.
Conversely, the ssh-agent is hacked. If some process writes on its socket asking for authentication info, the agent can run a script which obtains the password, mounts the crypto filesystem (which stores the encrypted key) and pipes the password into ssh-add. It would be helpful to preload into ssh-agent a list of key fingerprints that would be forthcoming if this were done; if a process requested authentication against a public key not on the list, the agent could reject the request without hassle. None of this intelligence is in the existing ssh-agent; it would have to be hacked in.
Somewhere in the bowels of the Maemo distro there must be a power management script that runs when the machine goes to sleep, specifically when inactivity is long enough that it wants to blank the screen. This script will get an added section to clear the ssh-agent and unmount the crypto filesystems.
But I want to have this machine ready for a trip to Europe a month from now. How much security can I get in that time?
Right now the sensitive data is limited to my SSH key, my GPG key, and an encrypted file containing my passport number and my ATM code. There are no daemons needing unencrypted host keys, no X.509 certificates, and no stealable secret work products. On this time scale, only the ssh-agent is relevant.
I've written a wrapper script over slogin and ssh, which checks if the ssh-agent is running and has keys, runs and stuffs it if not, and then execs the real ssh.
So far I have not located the sleep-time power management script, if it even exists. The ssh wrapper has an option to kill ssh-agent, which I will have to remember to do.
I expect to remember my ATM code, but if not, I will use my standard wrapper script to display the encrypted file safely, without using gpg-agent.
Where does the BIOS pass number fit into this picture? The password on the Cryptographic Vault has to be good enough to protect the most important secret, and four digits are far too weak. Also, the BIOS pass number only is engaged upon positive user action (turning over the cover, or the power menu), and we need security actions at the screen blank timeout; review the spilled soup scenario. However, you don't want to deliver a working PDA to a casual thief, and a wimpy four-digit BIOS pass number could be good enough for that protection. Remember, however, that a savvy recipient of stolen goods could and should simply re-flash the filesystem image, probably yielding a working machine.
How helpful would a fingerprint reader be? I'm thinking of a role generally parallel to the BIOS pass number. But print images change, e.g. with injury or dirt, so the reader could not be too picky in matching, and also there would have to be a non-biometric authentication mechanism. If that mechanism were the four-digit BIOS pass number, then the authentication system would be only as strong as its wimpiest branch. Even so, print reading is a whole lot less hassle than entering a number, and I would recommend including such a reader in future models of the N-Series.