| February 17, 2009 8:00 PM PST | |
by Alan Zeichick
The race is on, to build new applications that leverage the unique capabilities of mobile platforms such as notebooks, PDAs, and smartphones, or to retrofit existing applications with mobile-aware functionality. Despite the challenges of "mobilizing" applications regarding architectural, performance, and user-interface implications of occasionally connected computing, it's easier than ever for developers to create mobilized applications, thanks to embedded Java* and the .NET* Compact Framework.
On the other hand, there's a new category of challenges facing Independent Software Vendors (ISVs): Mobilized security.
Some of these security concerns may be obvious. Others are less so, and might not even be considered by ISV developers--until they're questioned by worried customer prospects. Let's take a look at some of the major security issues facing mobile developers, along with some brief ideas on how to address them within your hardware choices, system configuration, software tools or applications architecture.
Your author once dropped a Palm PDA at O'Hare airport. Fortunately, it was found and returned intact by airport security. But what if someone had looked through it for critical information, such as access codes or logins? What if someone pilfered the appointment schedule to determine travel dates to key clients? What if someone accessed e-mail records, or pulled other secret information out of the machine, such as remote-access dialup numbers and administrative passwords?
Not only could the loss of a handheld or notebook lead to possible identify theft (how many people have their home address, social security number or credit-card numbers somewhere on their PC's file system?), but the data in that machine could have critical business value, and losing it could have both competitive and legal implications.
Considering the recent headlines about stolen laptops of government officials, and of machines containing lists of social-security numbers and credit-card data, IT management should plan for the loss of a mobile device -- including the personal laptops and PDAs of employees who may be storing confidential company information or sensitive applications, or be using the device for VPN access to the enterprise LAN. A similar threat would be the loss or theft of a USB memory key, Compact Flash card or other removable media containing data. Not only would such a theft be easier because the item is pocket-sized, but it may not be noticed for hours or days.
The data within a WiFi-enabled mobile device could be stolen -- even if the device isn't. How? An easy way would be to secretly enable file sharing on the device, while also turning off any firewalls and other protections; for a skilled Windows* or Linux* hacker, this would only take a moment. Then, the data could be slowly sucked off the machine while its owner sips a latte.
Less dramatic, but equally possible, would be to copy selected data from the machine -- including application binaries, configuration files, messaging files, personal-information-manager data, or even caches and registry data -- to a storage device. Again, a USB memory key would do the trick; so too would a portable FireW ire or USB hard drive, even a CD-R burner if the device was available for a long enough period.
While installable binaries would be extremely valuable property, in many ways stolen data files are just as worrisome to enterprise security managers. Data files, whether in flat files, relational databases or in XML, could include source code, product designs, customer references, business plans or other intellectual property. Their loss or capture could do immense harm to a business.
Non-data files, such as caches, configuration files, "preferences" and registry keys, might allow the application to be installed or run on a second machine. Even if not, those files might include sensitive data, such as customer information, embedded passwords, encryption keys, network IP addresses and TCP port numbers, or other material that could be used to reverse-engineer hacks into a secure data center.
If any of these files can be copied from the machine, they can be carefully analyzed -- without the mobile device's user ever realizing that the data was stolen.
While theft of a device's data may seem far-fetched, unauthorized use of a machine certainly is not. If a device user leaves the computer unattended -- which may happen in any number of places, including customer sites during a coffee break, in airport lounges, coffee shops, or elsewhere -- someone else may be able to gain access to it.
The good news is that unless the hacker is completely prepared for the situation, and has sufficient time to work with the machine, there may little long-term harm that can be done. However, that's not guaranteed. The hacker may be able to install a virus, back-door keyboard logger, remote control software or other malicious software onto the machine. If the user is logged in and has active secure sessions running against an enterprise application, or is using a VPN, the unauthorized user may be able to search and retrieve selected information from within the company's critical applications or servers.
If the device's owner is logged in as an administrator, the unauthorized user may even be able to set up fictitious accounts or access privileges for his/her own machine. Far-fetched? Maybe -- but imagine what a discontented former employee, with technical knowledge and experience with the IT infrastructure, could do with only ten minutes on an authorized remote workstation. It's worth pondering restricting some administrative capabilities of remote or mobile users.
How many of your customers or end-users store access numbers, user names and passwords in their personal information manager? Do any of them have files called password.doc somewhere on their hard drive? While it's easy to spot sticky notes with usernames and passwords stuck on monitors and cubicle walls, it's less easy to eliminate electronic sticky notes stuck on your hard drive. Such files could be easily and swiftly found by combining through a stolen notebook, PDA or even smartphone, or retrieved by searching through caches, data bases, or other stolen files as mentioned earlier.
Even if an enterprise has a strong password policy, such a policy could be undermined and circumvented by unauthorized users. That's because certain user-friendly features -- such as Internet Explorer's* ability to automatically fill in username and password fields -- could be used by anyone with access to a notebook. Similar vulnerabilities are present in e-mail software, dial-up access software, even VPN* software. "Keychain"-style single sign-on software (SSO) can also be a vulnerability: if the user has set up a low-security password for SSO, strong enterprise passwords are irrelevant. This is particularly a problem when the end user is using his/her own phone, PDA or notebook to run enterprise apps, because IT may not be able to set or enforce password policies.
The above items should be a cause for concern for ISVs and IT professionals, especially since mobilized applications are containing more proprietary information than ever before, and because WiFi and other broadband remote-access technologies are allowing mobilized applications deeper access into enterprise networks and applications. Fortunately, there are steps that ISVs, developers, Web administrators and networking staff can take in order to improve mobile device security.
One such step is to take advantage of the hardware security built into many devices, such as BIOS-level passwords. Of course, end users will attempt to disable such security, so it must be implemented properly. However, bear in mind that such protection is hardly foolproof against tampering or hacking. Also, ensure that the device has a login (operating system) password, and if possible, disable the automatic storing of passwords by the operating system or by Web browsers. For example, if you're deploying PocketPC devices, you can set up a power-on password. You may even be able to password-protect its CompactFlash* cards. For information on securing PocketPC devices, see Microsoft's "How To: Increase Information Security on the Pocket PC*."
For additional protection against theft of the device, or unauthorized copying of its data, consider encrypting the entire file system of the laptop or device; if that's not possible, use cryptography to protect databases and key files that belong to specific enterprise-focused applications. In some cases, encryption may be a feature of the embedded database engine being used; in other cases, you may need to manually develop a crypto scheme for your data. One popular embeddable database engine, Berkeley DB* from Oracle SleepyCat*, supports Advanced Encryption Standard (AES) encryption of the database, which is intended to protect applications from an attacker gaining physical access to the media on which the database is stored. You can read more about the crypto features at http://www.oracle.com/database/berkeley-db/index.html*. Other embedded database engines also offer cryptography features, including Microsoft's SQL Server CE 2.0*.
While it may be hard to encrypt caches or registry keys, try to use good programming techniques to limit the amount of sensitive information that's stored in such locations, or which is beyond your control. Whenever possible, aggressively clear caches and other "plain text " files used by the application periodically during execution, and certainly upon exiting the application--don't leave anything incriminating behind!
End users may complain, but implement time-outs for applications or remote access sessions that are sitting unused, and if the computer goes into a sleep state, make sure that core applications are "logged out," or at least require a password to resume functioning. End users may set up password-protected screen savers; don't trust them as part of your security planning. In fact, ISVs and enterprise developers should generally assume that the operating system and hardware are insecure or could be compromised, and develop their own security procedures for enterprise applications and remote access that don’t rely on the OS.
Passwords are always an issue, of course. Biometrics and USB tokens can certainly assist with increasing security, and could be used for unlocking the computer, launching applications and authenticating remote-access sessions and other secure data transfers. A popular USB token is HARP* from Aladdin*; in many cases, a token might be the easiest way to enforce security on a mobile device, whether company-provided or personally owned by the employee.
When tokens or biometrics can't be used, consider a server-driven "challenge/response" system after the Windows-based application or VPN login. A second layer of access, beyond the ability of the operating system to "memorize" the username and password, and which are only transferred during an encrypted session, would add to security. Of course, all browser-based login screens should themselves be encrypted using Secure Socket Layer (SSL) — nothing goes in plain text!
The list of problems and solutions mentioned above are only the tip of the iceberg. While security issues should not prevent your organization from developing valuable applications, or stop customers from deploying them, it's important to face these issues up front. Careful design of applications and systems, and the proper architecture of custom-written code to handle security, is key to ensuring that we win the race to build secure, genuinely useful, mobilized solutions.
Intel® Centrino® Mobile Technology
Intel® Mobile Developer Community
A former mainframe software developer and systems analyst, Alan Zeichick is principal analyst at Camden Associates, an independent technology research firm focusing on networking, storage, and software development.
For more complete information about compiler optimizations, see our Optimization Notice.
