towards a unified framework for mobile device security
play

Towards a Unified Framework for Mobile Device Security Wayne A. - PowerPoint PPT Presentation

Towards a Unified Framework for Mobile Device Security Wayne A. Jansen, NIST Mobile Device Background* Mobile Device Background* Mobile Device Background* Mobile Device Background* Inexpensive, ubiquitous, wireless, networked,


  1. Towards a Unified Framework for Mobile Device Security Wayne A. Jansen, NIST

  2. Mobile Device Background* Mobile Device Background* Mobile Device Background* Mobile Device Background* • Inexpensive, ubiquitous, wireless, networked, expandable • Increasingly hold sensitive information or the means to access sensitive information • At the fringe of corporate influence and control • Physical security exposure to theft or loss • Limited computing power, display size, battery life • Intermittent connectivity • Many devices per user • Many operating systems – Palm OS, Pocket PC, Linux • Users unaware of security implications • Lack of adequate security mechanisms *Commercial products and trade names are identified in this presentation to illustrate technical concepts; it does not imply recommendation or Mobile Security Project endorsement by NIST

  3. Security Enhancements User Authentication Framework Components Content Policy Controls Encryption Network Authentication Firewall/IDS Anti-Virus VPN Mobile Security Project

  4. Framew ork Components • Piecemeal add-on security solutions often present problems in software integration, usability, and administration. • As an alternative, we have developed a unified framework that incorporates the following core security components: – User Authentication – Strong user authentication is the first line of defense for an unattended, lost, or stolen device. Multiple modes of authentication increase the work factor for an attacker; however, very few devices support more than one mode, usually password-based authentication – Content Encryption – With sufficient time and effort an authentication mechanism can be compromised. Content encryption is the second line of defense for protecting sensitive information – Policy Controls – When a device is active, various attacks can occur. Policy rules, enforced for all programs regardless of associated privileges, protect critical components from modification and limit access to security-related information Mobile Security Project

  5. Framew ork Schema Multi-mode Content Policy Controls Authentication Encryption • Required Effective Cryptographic • Authentication Policy Repository • Zero or Level 3 Policy C Yes/No More Zero or Policy B Yes/No Level 2 More Zero or Yes/No Policy A Level 1 More M i n None – default at Most Unavailable Level 0 power on and boot Restrictive up Mobile Security Project

  6. Example Configuration Required Effective Cryptographic Authentication Policy Repository All PIMS & wireless Token with socket Available L2 - Medium restrictions All PIMS, but no Password Unavailable L1 - Low communications None – default at Most Unavailable L0 - Locked power on and boot Restrictive up Mobile Security Project

  7. Example Configuration (cont.) Required Effective Cryptographic Authentication Policy Repository All PIMS with no L3 - High Token wireless socket Unavailable restrictions All PIMS & wireless None – user Available L2 - Medium with socket choice restrictions A few basic PIMS, Password, Available L1 - Low IrDA, Bluetooth Biometric None – default at Most Unavailable L0 - Locked power on and boot Restrictive up Mobile Security Project

  8. Conceptual Operation 1 p Delay Auto Auto/Man Fail Tran 1 Tran 3 1A 3 p Auto/Man Delay Pass Tran 3 Fail Fail 1B 3A Power Man Tran 2 Pass Pass On 0 1 p 3 p 1 2 3 Man Tran 1 Auto/Man Tran 2 Man Tran 0 Man Tran 1 Man Tran 0 Conventions: Man Tran 0 # -- echelon level # # p – pre-handler for level # # p – post-handler for level # Mobile Security Project # α – authentication mechanism α at level #

  9. Level Selector • An echelon selector GUI is used to navigate among echelon levels as needed • The buttons at the center are used to change levels • A change in level may trigger the execution of one or more authentication modules • The button for the current echelon level is highlighted • A slider at the left sets the maximum level to which the device can transition automatically • An icon is used to display the current echelon level and launch the Level Selector Mobile Security Project

  10. Authentication Modules • We are developing authentication modules for the framework that include visual authentication and novel forms of smart cards • The traditional means for user authentication is an alphanumeric password, but a number of drawbacks exist for handheld devices, such as the lack of a full keyboard • Moreover, translating existing desktop solutions to handheld devices can be problematic: – Obstacles include computational speed, network connectivity, battery capacity, and supported hardware interfaces – Any inconvenience due to a cumbersome peripheral attachment, lengthy authentication process, or error-prone interaction discourages use – Handheld devices have features (e.g., power-on/off behavior) that need addressing Mobile Security Project

  11. Picture Passw ord • During enrollment, the user selects a sequence of images, which must be entered for any subsequent login attempt • The software supports several different themes and user-defined images/themes • Two selection methods are provided: single (single tap) and paired (tap-and-hold, tap) • The password generated from the image sequence is used to authenticate the user • Reenrolling the same image sequence results in a different password value • Shuffling images between authentications is an option Mobile Security Project

  12. Smart MultiMedia Card • The mechanism relies on a smart card chip packaged in a multimedia card format • The authentication mechanism adjusts the echelon level on insertion or removal of a valid card and entry of its PIN • In addition to its smart card capabilities, the card functions as a memory device • This technology eliminates the need for an expansion sleeve, smart card reader, and full sized smart card that would otherwise be needed Mobile Security Project

  13. Proximity Token • Instead of bringing a token into physical contact with a PDA, LED Indicators use a short distance wireless interface • A challenge-response protocol Power periodically verifies the Switch presence of the device • If verification or communications between the token and the device fail, the PDA shuts down Conceptual Illustration of the • The proximity token has its Solution in a Key Fob own battery and been Form Factor prototyped using both Bluetooth and near-field magnetic communications Mobile Security Project

  14. Bluetooth Smart Card • Rather than bringing a smart LED Indicators card into physical contact with a PDA, use a wireless interface instead LCD • Bluetooth is present on most Screen Power handheld devices – no Switch specialized smart card reader 0 1 2 3 is needed by the PDA or Control 4 5 6 7 another computer Keys • Unlike wireless smart cards, C 8 9 E which draw power directly from the PDA, the Bluetooth smart card token has its own Conceptual Illustration of the battery Solution in a Key Fob Form Factor • The device also houses a smart card and Bluetooth radio – it could be a cell phone Mobile Security Project

  15. Implementation Authentication Level Opie Information Selector Picture UI Plug-in Password Socket Handler 1 Picture Socket Multiplexer Password UI Other Handler 3 Other UI • • • User Space Kernel Space Policy Enforcement Linux Kernel Power on Event Multi-Mode Authentication Secure Repository Mobile Security Project

  16. Policy Expression • Policy is represented by a set of policy entries • The policy language follows a grant-style specification by which all actions are denied unless enabled by a policy entry • Policy entries are a triple of action , source , and target values – Action refers to operations performed at the PDA, such as enabling an interface or accessing a file – Source refers to objects (resources or services) on the PDA, such as interfaces for PC cards, the serial port, or connections via Bluetooth, 802.11, etc. – Target refers to external points of interface or reference needed to complete the semantics of the operation – Web access example: action="socket" source="out:inet:*:129.6.0.0/16:80" target="*" Mobile Security Project

  17. Policy Representation • X.509-formatted certificate: Version Owner Issuer Issuer Signature Signature Algorithm ID Represented Certificate Serial Number In XML Validity Period PDA Policy Attributes Rules Issuer Unique ID Extensions <policyEntry action="socket" source="out:inet:*:129.6.0.0/16:80" target="*" /> Mobile Security Project

  18. Framew ork Recap • Generic multi-policy level framework for centrally assigning and administering security policies on handheld devices – Externally represented security policy, with an extensible policy language and format – Multi-mode authentication and content encryption at any policy level – Policies can be conveyed within certificates and handled as part of a policy management infrastructure – Simple policy perspective for users – Easy to navigate among echelon levels – Several suitable authentication mechanisms including visual login and novel forms of smart cards Mobile Security Project

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend