Wireless communication is inherently insecure. My consulting experience has confirmed that some organizations understand this fact when connecting to wireless networks with their laptops. However, their awareness falters when connecting their mobile devices to the same networks. According to a Echoworx study, 44% of the surveyed audience at London’s Infosecurity Europe 2011 conference transmitted sensitive information unencrypted to the Internet via their mobile devices.
OWASP cites spoofing attacks and surveillance as significant when using wireless communications with a mobile device. Wifi, 3G, GSM, CDMA & bluetooth; these are but a few transport protocols targeted to affect the confidentiality and integrity of the transmitted data. The controls discussed in this installment are designed to make successful exploits more difficult and to obfuscate the data to the point that successful exploits will result in no return for the attacker.
SSL vs. TLS
SSL and TLS provide an end-to-end secure communication channel, but they support different encryption algorithms. For example, SSL does not support 3DES or AES encryption; algorithms required by applications that handle sensitive data such as user credentials, as well as personal or business-critical information. Data classification and organizational requirements will influence which one is implemented on a device. All Federal information systems that transmit sensitive information, for example, require the use of TLS.
Encryption Algorithms
The selection of encryption algorithms to support a mobile device will be determined by data classification considerations and business requirements. Several vendors in the defense industry, for example, are developing FIPS 140-2 validated devices to support applications used by the DoD and NSA. Some private industry applications may require similar encryption levels, but most use cases can be accommodated with SSL or TLS.
OWASP recommends that strong encryption algorithms and key lengths be used to protect data in motion. It also recommends that only signed certificates be allowed and that they are associated with reputable certificate authorities. Signed certificates allow you to verify the source and validity of an encryption certificate, countering unsigned certificates often employed by attackers to gain access to information. Additionally, it is imperative that chain validation is implemented when chained SSL certificates are used. The encryption management system on the device should make it possible for the user to determine the validity of a certificate via the user interface.
Lastly, the device should employ mechanisms that mitigate the threat of man-in-middle attacks such as SSL strip. These attacks take advantage of SSL connections that do not verify the identity of the remote server. This allows an attacker to intercept communications, determine the encryption key and decrypt the data in transit. Countermeasures employ various techniques to verify the communicating devices and the integrity of the encryption information.
The next installment of this series will explore user authentication/authorization and session management. McAfee’s solutions to this problem space will be detailed and mapped to OWASP recommendations. Until then, be sure to follow us on @McAfeeBusiness for regular updates on McAfee happenings and news.
By: Steven Fox
