Guide to Bluetooth Security phần 4 pot

GUIDE TO BLUETOOTH SECURITY Checklist Security Need, Requirement, or Recom- Security Recommendation Should Justification mended Status Consider Practice Operational Recommendations 22 Ensure that Bluetooth devices are turned off when they are not used. Bluetooth capabilities should be disabled on all Bluetooth devices, except when the user explicitly enables Bluetooth to establish a connection. Shutting down Bluetooth devices when not in use minimizes exposure to potential malicious activities.  23 Perform pairing as infrequently as possible, ideally in a secure area where attackers cannot realistically observe the passkey entry and intercept Bluetooth pairing messages. (Note: A “secure area” is defined as a non-public area that is indoors away from windows in locations with physical access controls.) Users should not respond to any messages requesting a PIN, unless the user has initiated a pairing and is certain the PIN request is being sent by one of the user’s devices. 19 Pairing is a vital security function and requires that users maintain a security awareness of possible eavesdroppers. If an attacker can capture the transmitted frames associated with pairing, determining the link key is straightforward for pre-v.2.1 devices (security is solely dependent on PIN entropy and length). This is also recommended for v2.1 devices, although similar attacks against Secure Simple Pairing have not yet been documented.  24 A service-level security mode (i.e., Security Mode 2 or 4) should only be used in a controlled and well-understood environment. Security Mode 3 provides link-level security prior to link establishment, while Security Modes 2 and 4 allow link-level connections before any authentication or encryption is established. It is highly recommended that devices use Security Mode 3. (However, note that v2.1 devices cannot use Security Mode 3.)  25 Ensure that portable devices with Bluetooth interfaces are configured with a password to prevent unauthorized access if lost or stolen. Authenticating users to a portable Bluetooth device is a good security practice in the event the device is lost or stolen, which provides a layer of protection for an organization’s Bluetooth network.  26 In the event a Bluetooth device is lost or stolen, users should immediately unpair the missing device from all other Bluetooth devices with which it was previously paired. This will prevent an attacker from using the lost or stolen device to access another Bluetooth device owned by the user(s).  19 Derived from requirement 2.2 in DoD’s Bluetooth Smart Card Reader Security Requirements Matrix (01 June 2007), available at http://iase.disa.mil/stigs/checklist/DoD-Bluetooth-Smart-Card-Reader-Security-Requirements-Matrix.pdf 4-8 GUIDE TO BLUETOOTH SECURITY Checklist Security Need, Requirement, or Recom- Security Recommendation Should Justification mended Status Consider Practice 27 Install antivirus software on Bluetooth-enabled hosts that are frequently targeted by malware. Antivirus software should be installed on frequently targeted Bluetooth-enabled hosts to ensure that known malware is not introduced to the Bluetooth network. Organizations may also choose to deploy antivirus software on less- often targeted Bluetooth-enabled hosts.  28 Fully test and deploy Bluetooth software patches and upgrades regularly. Newly discovered security vulnerabilities of vendor products should be patched to prevent malicious and inadvertent exploits. Patches should be fully tested before implementation to ensure that they work.  29 Users should not accept transmissions of any kind from unknown or suspicious devices. These types of transmissions include messages, files, and images. With the increase in the number of Bluetooth-enabled devices, it is important that users only establish connections with other trusted devices and only accept content from these trusted devices  30 Fully understand the impacts of deploying any security feature or product prior to deployment. To ensure a successful deployment, an organization should fully understand the technical, security, operational, and personnel requirements prior to implementation.  31 Designate an individual to track the progress of Bluetooth security products and standards (perhaps via the Bluetooth SIG) and the threats and vulnerabilities with the technology. An appointed individual designated to track the latest technology enhancements, standards (perhaps via Bluetooth SIG), and risks will help to ensure the continued secure use of Bluetooth.  Table 4-3 provides guidelines and recommendations on Bluetooth headsets based on the Department of Defense’s (DoD) Bluetooth Headset Security Requirements Matrix (Version 2.0, 07 April 2008) 20 . These recommendations are only intended for situations where the organization is concerned about threats within physical range of the Bluetooth headset usage. Note that most commercially available Bluetooth headsets, handsets, and hands-free devices cannot be configured to meet the recommendations in Table 4- 3. Most of those devices do not provide encryption and often use a four-digit PIN with a default value like “0000” that cannot be changed. 20 http://iase.disa.mil/stigs/checklist/dod_bluetooth_headset_security_requirements_matrix_v2-0_7april2008.pdf 4-9 GUIDE TO BLUETOOTH SECURITY Table 4-3. Bluetooth Headset Security Checklist Checklist Security Recommendation Security Need, Requirement, or Justification Recom- mended Practice Should Consider Status 1 Bluetooth v1.2 or later should be used. The Bluetooth 1.2 specification deprecated the use of unit keys for link key generation. It also included enhancements such as adaptive frequency hopping (AFH) which improved resistance to radio frequency interference in the crowded 2.4 GHz band (which is used by IEEE 802.11b/g and other protocols).  2 Bluetooth radios should be Class 2 or Class 3. Bluetooth Class 1 radios provide 100mW of power with an approximate range of 100 meters, which facilitates discovery and eavesdropping by attackers.  3 Bluetooth pairing passkeys should be at least eight decimal digits in length and generated randomly for each pairing. For pre-v2.1 devices, this is essential to prevent link key cracking if pairing messages have been successfully eavesdropped by an attacker. Note that v2.1 devices using the Numerical Comparison or Passkey Entry association models will always use a 6-digit passkey per the Bluetooth specification. This is currently deemed adequate since v2.1 passkeys used during Secure Simple Pairing—by design—cannot be used to derive the associated link key.  4 Perform pairing as infrequently as possible, ideally in a secure area where attackers cannot realistically observe the passkey entry and intercept Bluetooth pairing messages. (Note: A “secure area” is defined as a non-public area that is indoors away from windows in locations with physical access controls.) Key establishment is a vital security function and requires that users maintain a security awareness of possible eavesdroppers. If an attacker can capture the transmitted frames associated with pairing, determining the link key is straightforward for pre-v.2.1 devices (security is solely dependent on PIN entropy and length). This is also recommended for v2.1 devices, although similar attacks against Secure Simple Pairing have not yet been documented.  4-10 GUIDE TO BLUETOOTH SECURITY Checklist Security Need, Requirement, or Recom- Security Recommendation Should Justification mended Status Consider Practice 5 The Bluetooth headset/audio gateway device should remain undiscoverable to other Bluetooth devices at all times other than the initial pairing process. It should only support the minimal amount of Bluetooth services required for use as a headset for a handheld device. While a Bluetooth device is in discoverable mode, any inquiring device within range can capture important connection information including device address and clock, which is the first stage of any Bluetooth attack.  6 Bluetooth Security Mode 3 (link level security) should be used by both the headset and the audio gateway device along with 128- bit Bluetooth encryption. Security Mode 3 provides link-level security, which requires authentication and encryption prior to link establishment. (However, note that v2.1 devices cannot use Security Mode 3.) 128-bit encryption is the maximum provided by the Bluetooth specification, so it should be used to mitigate potential attacks against lower entropy (weak) cryptographic keys.  7 Devices should support only a single headset connection between one headset and one handheld device or audio gateway device. Bluetooth headset support for multiple simultaneous connections would provide an additional attack vector.  8 The user should be able to authorize all initial incoming connection requests, and there should be an indication of any active Bluetooth link on both the handheld device and the Bluetooth headset. The user should be made aware of, and explicitly authorize, all connections associated with the headset to preclude potential attacks.  9 Bluetooth stack lockdown techniques should be used on the handheld device to disable unauthorized Bluetooth connections (headset profile and serial port profile are authorized). Unnecessary Bluetooth services, user controls, and applications should be either removed from the handheld device or reliably disabled permanently so that users cannot enable them. Note: This feature may already be included with the handheld device security policy manager. The Bluetooth stack on the handheld device should only support the minimal services/profiles approved for use. Supporting unauthorized services/profiles could introduce vulnerabilities.  4-11 GUIDE TO BLUETOOTH SECURITY Table 4-4 provides recommendations on Bluetooth smart card readers based on DoD’s Bluetooth Smart Card Reader Security Requirements Matrix (01 June 2007) 21 . Note that FIPS-140 validated encryption is recommended in addition to native Bluetooth authentication and encryption. Table 4-4. Bluetooth Smart Card Reader Security Checklist Checklist Security Recommendation Security Need, Requirement, or Justification Recom- mended Practice Should Consider Status 1 Bluetooth mutual authentication, 128-bit Bluetooth encryption, and FIPS 140-validated cryptography should all be used for all communications between the smart card reader and the host device. Strong authentication and encryption is essential to network security, especially wireless connections. Mutual authentication confirms both devices have the appropriate link key, and 128-bit encryption is the maximum key length provided by the Bluetooth specification. FIPS 140- validated cryptography should also be used to compensate for weaknesses in the native Bluetooth encryption.  2 Bluetooth pairing passkeys should be at least eight decimal digits in length and generated randomly for each pairing. For pre-v2.1 devices, this is essential to prevent link key cracking if pairing messages have been successfully eavesdropped by an attacker. Note that v2.1 devices using the Numerical Comparison or Passkey Entry association models will always use a 6-digit passkey per the Bluetooth specification. This is currently deemed adequate since v2.1 passkeys used during Secure Simple Pairing—by design—cannot be used to derive the associated link key.  3 Perform pairing as infrequently as possible, ideally in a secure area where attackers cannot realistically observe the passkey entry and intercept Bluetooth pairing messages. (Note: A “secure area” is defined as a non-public area that is indoors away from windows in locations with physical access controls.) Key establishment is a vital security function and requires that users maintain a security awareness of possible eavesdroppers. If an attacker can capture the transmitted frames associated with pairing, determining the link key is straightforward for pre-v.2.1 devices (security is solely dependent on PIN entropy and length). This is also recommended for v2.1 devices, although similar attacks against Secure Simple Pairing have not yet been documented.  4 Bluetooth mutual authentication should occur immediately after the initial establishment of any Bluetooth connection. Devices should authenticate each other as soon as possible and certainly before providing access to any offered services.  21 http://iase.disa.mil/stigs/checklist/DoD-Bluetooth-Smart-Card-Reader-Security-Requirements-Matrix.pdf 4-12 GUIDE TO BLUETOOTH SECURITY Checklist Security Need, Requirement, or Recom- Security Recommendation Should Justification mended Status Consider Practice 5 The Bluetooth smart card reader should remain undiscoverable to other Bluetooth devices at all times other than the initial pairing process and cannot initiate Bluetooth connections on its own. It should only support the minimal amount of Bluetooth services required for use as a smart card reader for a single host device. While a Bluetooth device is in discoverable mode, any inquiring device within range can capture important connection information including device address and clock, which is the first stage of any Bluetooth attack.  6 Unnecessary Bluetooth services, user controls, and applications should be either removed from the host device or reliably disabled permanently. The Bluetooth stack on the host device should only support the minimal features approved for use. Supporting other features could introduce vulnerabilities unnecessarily.  7 All Bluetooth profiles except for Serial Port Profile should be disabled at all times, and the user should not be able to enable them. Additional profiles could introduce vulnerabilities unnecessarily. The Serial Port Profile is the only profile needed for smart card readers.  4-13 GUIDE TO BLUETOOTH SECURITY Appendix A—Glossary of Terms Selected terms used in the publication are defined below. Access Point (AP): A device that logically connects wireless client devices operating in infrastructure to one another and provides access to a distribution system, if connected, which is typically an organization’s enterprise wired network. Ad Hoc Network: A wireless network that dynamically connects wireless client devices to each other without the use of an infrastructure device, such as an access point or a base station. Claimant: The Bluetooth device attempting to prove its identity to the verifier during the Bluetooth connection process. Flooding: An attack in which an attacker sends large numbers of wireless messages at a high rate to prevent the wireless network from processing legitimate traffic. Infrared (IR): An invisible band of radiation at the lower end of the electromagnetic spectrum. It starts at the middle of the microwave spectrum and extends to the beginning of visible light. Infrared transmission requires an unobstructed line of sight between transmitter and receiver. Infrastructure Network: A wireless network that requires the use of an infrastructure device, such as an access point or a base station, to facilitate communication between client devices. Jamming: A device emitting electromagnetic energy on a wireless network’s frequency to make it unusable. Media Access Control (MAC): A unique 48-bit value that is assigned to a particular wireless network interface by the manufacturer. Piconet: A small Bluetooth network created on an ad hoc basis that includes two or more devices. Range: The maximum possible distance for communicating with a wireless network infrastructure or wireless client. Scatternet: A chain of piconets created by allowing one or more Bluetooth devices to each be a slave in one piconet and act as the master for another piconet simultaneously. A scatternet allows several devices to be networked over an extended distance. Verifier: The Bluetooth device that validates the identity of the claimant during the Bluetooth connection process. Wireless Bridge: A device that links two wired networks, generally operating at two different physical locations, through wireless communications. Wireless Local Area Network (WLAN): A group of wireless AP and associated infrastructure within a limited geographic area, such as an office building or building campus, that is capable of radio communications. WLANs are usually implemented as extensions of existing wired LANs to provide enhanced user mobility. A-1 GUIDE TO BLUETOOTH SECURITY Wireless Personal Area Network (WPAN): A small-scale wireless network that requires little or no infrastructure and operates within a short range. A WPAN is typically used by a few devices in a single room instead of connecting the devices with cables. A-2 GUIDE TO BLUETOOTH SECURITY Appendix B—Acronyms and Abbreviations Selected acronyms and abbreviations used in the publication are defined below. ACO Authenticated Cipher Offset AFH Adaptive Frequency Hopping AP Access Point dBm Decibels referenced to one milliwatt DISA Defense Information Systems Agency DoD Department of Defense ECDH Elliptic Curve Diffie Hellman EDR Enhanced Data Rate FHSS Frequency Hopping Spread Spectrum FIPS Federal Information Processing Standard FISMA Federal Information Security Management Act GHz Gigahertz HCI Host Controller Interface IBC Iterated Block Ciphers IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPSec Internet Protocol Security IR Infrared ISM Industrial, Scientific, and Medical ITL Information Technology Laboratory Kbps Kilobits per second KG Key Generator KSG Key Stream Generator L2CAP Logical Link Control and Adaptation Protocol LAN Local Area Network LFSR Linear Feedback Shift Register LMP Link Manager Protocol MAC Medium Access Control Mbps Megabits per second MITM Man-in-the-Middle mW Milliwatt NFC Near Field Communication NIST National Institute of Standards and Technology OMB Office of Management and Budget OOB Out of Band B-1 GUIDE TO BLUETOOTH SECURITY P2P Peer to Peer PC Personal Computer PDA Personal Digital Assistant PHY Physical Layer PIN Personal Identification Number PKI Public Key Infrastructure RF Radio Frequency RNG Random Number Generator RSSI Received Signal Strength Indication SAFER Secure And Fast Encryption Routine SDP Service Discovery Protocol SIG Special Interest Group SP Special Publication SRES Signed Response SSP Secure Simple Pairing TDM Time Division Multiplexing USB Universal Serial Bus WLAN Wireless Local Area Network WPAN Wireless Personal Area Networks B-2 [...].. .GUIDE TO BLUETOOTH SECURITY Appendix C—References The list below provides references for the publication Bluetooth Special Interest Group, Bluetooth 2.0 and 2.1 specifications, http://www .bluetooth. com /Bluetooth/ Technology/Building/Specifications/ Bluetooth Special Interest Group, Bluetooth Security White Paper”, May 2002, http://www .bluetooth. com/NR/rdonlyres/E870794C-2788 -49 BF-96D3C9578E0AE21D/0 /security_ whitepaper_v1.pdf... http://www .bluetooth. com/NR/rdonlyres/E870794C-2788 -49 BF-96D3C9578E0AE21D/0 /security_ whitepaper_v1.pdf Bluetooth Special Interest Group, “Simple Pairing Whitepaper”, August 2006, http:/ /bluetooth. com/NR/rdonlyres/0A0B3F36-D15F -44 70-85A6F2CCFA26F70F/0/SimplePairing_WP_V10r00.pdf C Gehrmann, J Persson, and B Smeets, Bluetooth Security, Artech House, 20 04 Defense Information Systems Agency (DISA), “DoD Bluetooth Headset Security Requirements Matrix”,... Wool, “Cracking the Bluetooth PIN”, In Proc 3rd USENIX/ACM Conf Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005 C-1 GUIDE TO BLUETOOTH SECURITY Appendix D—Online Resources The lists below provide examples of online resources related to Bluetooth technologies and wireless network security that may be helpful to readers Documents Name URL Bluetooth SIG Specifications... http://www .bluetooth. com /Bluetooth/ Technology/Building/Spe cifications/ DoD Bluetooth Headset Security Requirements Matrix (Version 2.0, 07 April 2008) http://iase.disa.mil/stigs/checklist/dod _bluetooth_ headset_sec urity_requirements_matrix_v2-0_7april2008.pdf DoD Bluetooth Smart Card Reader Security Requirements Matrix (Version 2.0, 01 June 2007) http://iase.disa.mil/stigs/checklist/DoD -Bluetooth- Smart-CardReader -Security- Requirements-Matrix.pdf... http://iase.disa.mil/stigs/checklist/dod _bluetooth_ headset _security_ requirements_matrix_v20_7april2008.pdf Defense Information Systems Agency (DISA), “DoD Bluetooth Smart Card Reader Security Requirements Matrix”, Version 2.0, 01 June 2007, http://iase.disa.mil/stigs/checklist/DoD-BluetoothSmart-Card-Reader -Security- Requirements-Matrix.pdf Y Lu, W Meier, and S Vaudenay, “The Conditional Correlation Attack: A Practical Attack on Bluetooth. .. http://checklists.nist.gov/docs/SP_800-70_20050526.pdf NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices http://csrc.nist.gov/publications/nistpubs/800-111/SP800111.pdf NIST SP 800-1 14, User's Guide to Securing External Devices for Telework and Remote Access http://csrc.nist.gov/publications/nistpubs/800-1 14/ SP8001 14. pdf D-1 ... http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf NIST SP 800 -48 Revision 1, Guide to Securing Legacy IEEE 802.11 Wireless Networks http://csrc.nist.gov/publications/nistpubs/800 -48 -rev1/SP80 048 r1.pdf NIST SP 800-50, Building an Information Technology Security Awareness and Training Program http://csrc.nist.gov/publications/nistpubs/800-50/NIST-SP80050.pdf NIST SP 800-53 Revision 2, Recommended Security Controls for Federal Information... Electronic Authentication Guideline http://csrc.nist.gov/publications/nistpubs/800-63/SP80063V1_0_2.pdf NIST SP 800-63-1 (Draft), Electronic Authentication Guideline http://csrc.nist.gov/publications/PubsSPs.html NIST SP 800- 64, Security Considerations in the Information System Development Life Cycle http://csrc.nist.gov/publications/nistpubs/800- 64/ NIST-SP800 64. pdf NIST SP 800-70, Security Configuration... http://iase.disa.mil/stigs/checklist/DoD -Bluetooth- Smart-CardReader -Security- Requirements-Matrix.pdf FIPS 140 -2, Security Requirements for Cryptographic Modules http://csrc.nist.gov/publications/fips/fips 140 -2/fips 140 2.pdf FIPS 180-2, Secure Hash Standard (SHS) http://csrc.nist.gov/publications/fips/fips180-2/fips1802withchangenotice.pdf FIPS 197, Advanced Encryption Standard http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS 199, Standards for Security. .. Information Security: Federal Agencies Need to Improve Controls over Wireless Networks http://www.gao.gov/new.items/d05383.pdf GRS 24, Information Technology Operations and Management Records http://www.archives.gov/records-mgmt/ardor/grs 24. html NIST SP 800-30, Risk Management Guide for Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST SP 800-32, Introduction to . http://iase.disa.mil/stigs/checklist/dod _bluetooth_ headset _security_ requirements_matrix_v2-0_7april2008.pdf 4- 9 GUIDE TO BLUETOOTH SECURITY Table 4- 3. Bluetooth Headset Security Checklist Checklist Security Recommendation Security. vulnerabilities.  4- 11 GUIDE TO BLUETOOTH SECURITY Table 4- 4 provides recommendations on Bluetooth smart card readers based on DoD’s Bluetooth Smart Card Reader Security Requirements Matrix. http://www .bluetooth. com /Bluetooth/ Technology/Building/Specifications/ Bluetooth Special Interest Group, Bluetooth Security White Paper”, May 2002, http://www .bluetooth. com/NR/rdonlyres/E870794C-2788 -49 BF-96D3- C9578E0AE21D/0 /security_ whitepaper_v1.pdf