An overview of WiFi, Bluetooth, and cloud security.
While secure communication might be on everyone’s mind, few are aware of the layers of security already present, and what steps are required to make the future safer. This article summarizes some existing security mechanisms, and outlines a few principles that could shape the future of IoT and Cloud security.
Personal wireless security
How secure are you when streaming a TV show over Chromecast at home?
Your network at home employs personal security which authenticates client devices using a passphrase, and encrypts data using AES-CCMP (Advanced Encryption Standard-Counter Cipher Mode with Block Chaining Message Authentication Code Protocol) as defined by IEEE 802.11i. While AES by itself is a robust standard, AES-CCMP ensures privacy and integrity of data by using a 128-bit key to iteratively encrypt and authenticate 128-bit blocks of data to generate ciphertext.
When your smartphone or Chromecast asks to connect to your home access point, a four-way handshake takes place between the two to determine the authenticity of the client and to establish the security keys for encryption. Packets generated by your devices are encrypted with unique keys which are periodically changed, making it very hard for eavesdroppers to use your network.
The primary flaw with this method is the possibility that a sniffer captures a whole 4-way handshake and uses brute-force to decipher the security key. The security of a WLAN depends heavily on the complexity of a chosen PSK.
Typical office networks employ enterprise security, which uses AES-CCMP for encryption and IEEE 802.1X for authentication. The 802.1X standard supports a variety of EAP (Extensible Authentication Protocol) types. The EAP framework allows for mutual authentication between a client device and an authentication server via an authenticator, which use the RADIUS protocol to communicate.
EAP supports numerous authentication methods, such as one-time passwords, certificates, public key authentication, and smart cards, and 802.1x specifies how the EAP should be encapsulated in LAN frames.
Most EAP methods include two types of exchanges, the inner and the outer methods. As part of the outer methods, advanced EAP types (TLS, TTLS, LEAP, and PEAP) provide mutual authentication, and create an encrypted tunnel for all further exchanges. This helps tackle man-in-the-middle attacks. As part of the inner methods, tunneled mechanisms of EAP-TTLS and EAP-PEAP provide mutual authentication to other methods that utilize the familiar user ID/password methods (EAP-MD5, EAP-MSCHAP V2) in order to authenticate the client to the server.
Figure 1 A typical enterprise system
SSL/TLS: How secure are the passwords you send over the internet?
Most secure web servers make use of transport layer security (TLS/SSL) to protect communication between client and server. This is called public key cryptography and employs a trusted third party to verify the identity of a server and assist clients in corroborating this for every new connection. SSL uses a pair of public and private keys, where data encrypted by a universally accessible public key can only be decrypted by the corresponding private key. Although it is a sturdy mechanism, encryption/decryption with the public/private key pair for every exchange is computationally intensive and expensive. The public and private keys are therefore widely used only for the initial handshake phase to create a session key which is used for all further encryption.
When you enter an “https:”-prepended URL into your browser, the browser requests that the server identify itself. The server sends a hello message to the browser that includes a copy of its SSL certificate and its public key. The browser checks to confirm that the certificate comes from a trusted party, that it is currently valid, and that the certificate has a relationship with the site from which it’s coming. If all of the above check out, the browser trusts the server and sends back a symmetric session key encrypted using the server’s public key, which the server decrypts using its private key. All communication thereafter is carried out using the session key.
Figure 2 SSL/TLS handshake sequence
Wi-Fi offers multiple security techniques and procedures of varying strengths, but how does one ensure compliance and protection at the device level. Information security is an especially critical requirement in healthcare systems, with medical electronic devices being mandated to use strong encryption to protect data. The FIPS 140-2 standard lays out the requirements and standards to protect the encryption modules themselves – to protect the protector. It covers areas related to the secure design and implementation of a cryptographic module, including module specification, interfaces, authentication, key management, self-tests, and mitigation of attacks.
The Cryptographic Module Validation Program (CMVP)
Medical devices and systems are increasingly using Wi-Fi as the primary means of connectivity. Wi-Fi uses the Advanced Encryption Standard (AES) for encrypting data before transmission – and this standard meets FIPS 140-2 requirements on strength of encryption. However, CMVP involves several tests and the meeting of many other requirements before certification can be granted. As a prerequisite, a device needs to go through the Cryptographic Algorithm Validation Program (CAVP) that provides validation testing of FIPS-approved and NIST-recommended cryptographic algorithms and their individual components. The tests are conducted by accredited Cryptographic and Security Testing (CST) laboratories.
Figure 3 Functional architecture of a typical fully embedded Wi-Fi module
Security over Bluetooth
Wi-Fi may have multiple security mechanisms, but how secure is it to transfer data over Bluetooth?
The Bluetooth standard offers multiple levels of security (security modes, encryption modes, and service levels) for authentication, confidentiality, and encryption, and allows device manufacturers to choose a method best suited to the type of device and service.
Security mode 0 is a non-secure mode and does not adopt any mechanism to authenticate or encrypt data. Devices are exposed to threats and attacks in this mode. Security mode 2 employs a security manger that checks and regulates access to services and devices. Security mode 3 mandates authentication and encryption mechanisms for all data to and from a device. It also institutes security procedures before the establishment of the physical link. Security mode 4 also employs service level security wherein security procedures are employed after a link is set up.
Encryption modes define the type of encryption and provide data security from eavesdroppers. Encryption mode 1 is a no-encryption mode and does not offer any security. Encryption mode allows unicast data to be encrypted using link keys but leaves broadcast data unencrypted. All data is encrypted using a master link key when using encryption mode 4.
Bluetooth also allows two levels of trust and three levels of service security. The trusted and untrusted levels determine whether a device has a fixed relationship with another device with full access to all services or does not have an established relationship with another Bluetooth device. In an untrusted relationship, the devices can utilize a service level to afford regulated access to services. Service Level 1 requires authorization and authentication with automatic access to trusted devices. Service Level 2 requires only authentication, and Service Level 3 is open to all devices.
Cloud security encompasses a wide range of confidentiality, data integrity, and access controllability issues.
Cloud service providers (CSPs) constantly strive to ensure confidentiality and integrity of data. Some methods CSPs adopt to ensure confidentiality is that of advanced authentication and encryption protocols. For authentication, a popularly used protocol is OAuth, which is an HTTPS-based protocol that enables a user-agent like a browser to access a protected resource on a server using credentials stored on an authorization server. Advanced encryption mechanisms, among others, include complex and computationally intensive homomorphic encryption methods, which process encrypted data without exposing the plaintext, but are not suitable for larger data, and are very expensive.
Large CSPs expect customers to simply trust their data is secure and private, but have the option to access user data if required. The concept of Zero Knowledge encryption offers users the guarantee of airtight security because only the user holds the keys to decrypt their own data. This accords a user with ultimate control over their data and the flexibility to use cloud based services with highest security.
Even if data is encrypted in a failsafe manner, it is still prone to corruption and integrity issues at the time of outsourcing to the cloud, while in the cloud, or when downloaded. Message authentication code (MAC) algorithms are typically used to check the integrity of data. The data owner computes the MAC on his data and stores it. He then compares it every time thereafter with the newly computed MAC values. This allows accidental and intentional changes to be detected.
Access control ensures that users can only access data they are permitted to use by the owner. In enterprises, this is handled by maintaining distinct domains, user identity, and role management. For personal data, the majority of providers allow users to share their data with intended users and set permissions on the data. Intended users can use username/password-based authentication to access this data. For Zero knowledge security, sharing data with other users creates a backdoor entry for the cloud provider when they supply other users with access to shared data.
—Apurva Peri is an Associate Product Manager at Redpine Signals, and holds a Masters degree in Electrical and Computer Engineering from the National University of Singapore, and a Bachelors degree in Telecommunications Engineering from R.V.C.E. Bangalore.