NIST spells out baseline security requirements for next-gen mobile devices
The adoption of mobile devices in the workplace has outstripped the ability of smart phones and tablets to support basic security features needed in trusted enterprise tools.
As a result, government agencies are being forced to accept the security risks inherent in mobile devices because their workers expect to be able to use their own devices at work; also because agencies hope to improve productivity and save money, according to draft security guidelines from the National Institute of Standards and Technology. But these risks can be greater than those in traditional desktop and laptop computers.
“Current mobile devices lack the hardware-based roots of trust that are increasingly built into laptops and other types of hosts,” the publication says. Smaller form factors and power requirements have made the inclusion of security hardware components such as the Trusted Platform Module impractical.
TPM is a set of specifications from the Trusted Computing Group for implementing cryptography in silicon, which can be used to support data protection, communications security, strong authentication, identity management, network access control and nonrepudiation.
NIST does not specify technologies such as TPM for mobile devices, but lays out minimum requirements for creating trusted mobile platforms in Special Publication 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices.
The guidelines are intended to accelerate industry’s implementation of these foundational components and provide a baseline of security technologies across a wide range of devices. They are aimed at mobile operating system vendors, device manufacturers and security software vendors, as well as carriers and application developers, with the ultimate aim of improving the security of devices issued to agency workers as well as employee-owned devices.
Despite their popularity and potential benefits, the public sector has been slow to fully embrace employees’ use of mobile devices because of security concerns. A number of agencies have established pilot programs for bringing them into the workplace, and some have developed policies for use and management of the devices. NIST has produced Guidelines for Managing and Securing Mobile Devices in the Enterprise, but the underlying problem of what NIST calls fundamental security primitives needed in the devices must be solved by industry.
This requires implementing roots of trust -- functionalities that are secure by design and provide basic security functionality -- preferably in hardware.
The NIST publication identifies three basic issues to be addressed in mobile device development:
- Device integrity: The ability of a tablet or phone to provide information about its configuration, health and operating status that can be verified by the organization whose information is being accessed.
- Isolation: The ability to keep personal data and organization information and processes separate from each other.
- Protected storage: The ability to keep data safe using cryptography and restricting access to information on the device.
To provide these capabilities, the next generation of mobile devices will need a set “foundational security elements that can be leveraged by the device, OS and applications,” NIST says in the guidelines. These components are:
- Roots of trust. These are security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions for storage of keying material for cryptography and authentication; a protected engine for verification of digital signatures; device integrity; interfacing with reporting tools; and measurements supporting integrity assertions.
- An application programming interface to expose these roots of trust to the device and operating system, to establish a chain of trust for user applications.
- A policy enforcement engine to enable the processing, maintenance and management of polices on the mobile device for the control and protection of information.
The guidelines provide a sample architecture for implementing these fundamentals in the device.
Comments on the draft of SP 800-164 should be sent by December 14 to email@example.com.