Recommendations

Current implementations of Palm OS devices do not use any Flash memory for application data storage and is used solely to store the operating system itself. All applications and data reside on battery-backed RAM. Therefore, a trivial solution for security-critical deployments would be to use devices that store the OS in ROM (such as the PalmPilot family) or guarantee that the entire Flash device is read-only. A similar scenario (Figure 9) would be to use a ROM device for all boot loading and Flash memory upgrade routines, still leaving the actual operating system in Flash. This would allow the critical routines to be protected and still allow the OS to be upgraded. It is apparent that the current PDA model places convenience of OS upgrades of greater importance than security.

Figure 9: Possible design configuration for a secure PDA

A disadvantage to using Flash memory for the storage of applications and other often-modified data is the low amount of write-cycles (typically $\approx$10,000) guaranteed during the memory's lifetime. Given that RAM has no such limitation, it is still a natural choice for this type of data storage.

The Boot-Block areas of Flash memory could be used to implement a secure boot process similar to [1], which will guarantee the integrity of the system.

Implementing a hardware-based memory management unit (MMU) will aid in supplying memory isolation and preventing applications from unauthorized access to external memory. The MMU, commonly designed into embedded microprocessors, is not available in the DragonBall core. For purposes of Palm OS devices, this unit could be implemented in an application-specific IC (ASIC) or programmable logic device. It is hoped that an MMU is designed into the ARM core for future DragonBall processors. The MMU is located on the address and data buses between the microprocessor and the external memory. If the address requested for read/write access is outside of a legal, pre-defined range, the MMU can either prevent the operation outright or respond back to the processor in some manner.

It should be noted that solely implementing an MMU is not enough for proper memory protection. If the Palm OS is modified by an adversary, it may still be possible to access ``restricted'' areas of Flash. Using [1] in conjunction with an MMU implementation will work nicely, as there is integrity to guarantee that the operating system and underlying components are trusted and there is hardware-based memory protection for fault isolation. Figure 9 is one possible design configuration. The ROM and the MMU could be internal to the CPU, depending on its type. The MMU will monitor the address and data buses as described previously. The entire configuration could be designed as an ASIC or as a secure cryptographic coprocessor, along with the proper tamper-response and physical protection systems as recommended in [4,6].

Another solution to the problem of accessible Flash memory and risks of intentional corruption would be to introduce hardware jumper protection. This would physically allow or prevent writing to the Flash device. In order to accomplish this, a user would typically have to place a jumper or depress a button to enable or disable writing to Flash memory areas. Such a jumper could be connected to the Chip Enable, Write Enable, or Output Enable line of the memory device. Alternatively, it could enable circuitry that would connect the required address lines between the processor and memory device. When enabling field-upgradeable functionality, some modicum of due diligence must be taken to ensure integrity and authorization for such actions. Even if the hardware jumper was only active for the regions storing the base operating system, this would increase the security of the system. If applications are stored in Flash in future devices, the same scenario would exist and the user would have to physically ``approve'' each application as it is loaded into their device. This, however, is tedious for the user and could easily be bypassed with simple modifications to the hardware.

Secure coprocessors, such as [8,26], enable secure distributed applications by providing safe havens where an application program can execute, free of observation and interference by an adversary with direct physical access to the device [26]. Designing such a configuration into the underlying Palm OS hardware will greatly enhance the security of the device and may minimize enough risk to be a suitable platform for security-based applications. It is possible that smartcards can serve as interim cryptographic coprocessors for portable devices [28]. Additionally, [3] proposes a software-based solution of using PDAs as cryptographic tokens.

Currently, Palm OS devices are extremely vulnerable to Flash memory attacks and have no protection mechanisms as described in this section. This is quite possibly the case for other PDAs and portable devices, as well.