Secure private communications

Most physical network links provide poor guarantees of confidentiality and privacy. Local networks are increasingly wireless, and wide area networks are impossible to physically secure against pervasive surveillance. Therefore, any information from a user to a service or between users should preferably be encrypted using modern cryptographic techniques to render it unintelligible to eavesdroppers. All types of communications from the user should be protected: personal information or sensitive user input should be encrypted to preserve its privacy (and security); however, even accesses to otherwise public resources should be obscured through encryption to prevent an eavesdropper from inferring users’ patterns of browsing, profiling, service use [97] or extracting identifiers that may be used for future tracking.

4.3.1 Basic Encryption: client-service

Deployed cryptographic channels provide a high degree of confidentiality for communications be- tween clients and services when implemented and configured correctly. Widely deployed technolo- gies include the latest Transport Layer Security 1.2 (TLS1.2) [79], as well as the Secure Shell (SSH) pro- tocols [25]. Those technologies provide a confidential, and possibly authenticated channel between clients and end-services.

Both TLS and SSH use “public key cryptography” technologies that allow for encrypted channels to be set up without clients and servers sharing any prior secrets. However, TLS1.2 does rely on a public key certificate infrastructure of certificate authorities that is necessary to ensure the authenticity of the server end of the encrypted tunnels. Conversely, compromised authorities may lead to the security of channels being compromised. For public resources, accessible through web-browsers, a valid public key certificate is necessary and should be obtained. In case TLS is used within custom built software or mobile application, certificate pinning techniques may be used to avoid the need for a certificate from a globally trusted authority (Certificate Pinning [96]). Such a model should be preferred for in- ternal channels such as those used by application for software updates. SSH relies on manual user verification of the service key, which is more taxing on non-technical users. Such a model should only be deployed after user studies confirm users are capable of performing checks consistently and cor- rectly.

Deploying TLS 1.2, or an equivalent secure channel, for every network interaction should be consid- ered the current state of the-art. Detailed guidance about the currently recommended ciphersuites for both families of protocols is provided in the ENISA report on ciphers and key lengths[180]. A number of technologies may be used for communication within an organisation to protect user data in transit over networks. One such example is IPSec [92] that creates secure communication tunnels

34 _{This discussion sidesteps the issue of selectively disclosing attributes in a credential. Moreover, one can argue}

that Idemix is also based on the self-blinding principle as it randomises the signature on the credential before sending it to the verifier. Idemix can however not randomise all parts of the signature and hence needs to prove (in zero-knowledge) possession of an import component of that signature.

between networked machines, or between networks connected by public network links. It is recom- mended that traffic internal to an organisation (local-area network) is encrypted if it may contain user information, such as for performing back-ups or communications between application and database servers. Links over wide area networks, be it public or private (lease fiber / line) should always be encrypted due to the difficulty of guaranteeing the physical security of those channels. A number of mature Virtual Private Network (VPN) technologies and products are commercially available to protect such links.

4.3.2 Basic Encryption: end-to-end

A number of services, such as Voice-over-Internet-Protocol (VoIP), electronic mail or instant messag- ing and social networking mediate communications between end users. Such services should prefer to encrypt the communications between users in an end-to-end fashion, meaning the encryption is added at one user end-point and is only stripped at the other end-user end-point, making the content of communications unintelligible to any third parties including the service providers. While the service providers may wish to assist users in authenticating themselves to each other for the purpose of es- tablishing such an end-to-end encrypted channel, it is preferable, from a privacy perspective, that the keys used to subsequently protect the confidentiality and integrity of data never be available to the service providers, but derived on the end-user devices.

A number of services may require some visibility into the contents of communications for either rout- ing them to the correct destination, or providing value added services. In such cases the minimum amount of information should be exposed to the provider, and to the extent possible any manipula- tion of the content of communication should be performed on user devices and minimising the con- tent leaked to the service providers.

A number of technologies have been proposed, implemented and standardised to different extents to provide end-to-end confidentiality. The Pretty Good Privacy (PGP) [210] software as well as S/MIME standards [161] may be used to protect email correspondences end-to-end; the Off-The-Record mes- saging (OTR) [38] protocols are widely supported by clients software to protect instant messaging conversations. Mobile applications such as Whisper Systems’ TextSecure provide end-to-end en- crypted mobile chat; Crypto Phone and Red Phone provide end-to-end encrypted communications. As such the technology for providing end-to-end communications is mature, and provision of this prop- erty should be considered the state of the art.

4.3.3 Key rotation, forward secrecy and coercion resistance

Modern encryption technologies provide strong confidentiality guarantees, but only against eaves- droppers that are not able to get access to the secrets keys used to protect them. Those short binary strings therefore become valuable targets for theft, extortion, compromise through hacking or coer- cion.

To minimise the potential for keys to be compromised it is important to rotate keys regularly, there- fore minimising the exposure of private data in case of a key compromise. Modern cryptographic sys- tems, including some configurations of TLS (using the DH or ECDH cipher suites) and all configurations of OTR, provide forward secrecy, a property that guarantees the use of fresh keys for each communi- cation session and discarding of key upon session termination. Forward secrecy guarantees that after a communication session is over, the secret key material cannot be recovered, and therefore no amount of coercion can render the encrypted material intelligible. The provision of such automatic key rotation schemes should be considered.

The state of the art is for no long-term secrets to be used to protect the confidentiality of interactive end-to-end conversations. For asynchronous communications (such as email) regular key rotation should be enforced and automatically managed by state-of-the-art services and applications.