The Untrusted Server: The Real-World Impact of a Wickr Server Compromise

“The messages are encrypted end-to-end and both the encrypted messages and keys in the key pools are authenticated end-to-end. This means that attackers have no ability to read or modify encrypted messages as they pass through the server and they cannot manipulate the key pools to execute man in the middle attacks.”

Introduction

Wickr security is built on the concept of an untrusted server.  In other words, we aim to provide security even in the event of a “worst case” server breach, where an omnipotent attacker has full control of server resources, to include the ability to read and modify back-end application code and data and go undetected for some time.

Third-party experts have continuously vetted our end-to-end encryption and security from the start. As part of our recently released Customer Security Promises, a leading independent security firm validated that message content is not readable on our back-end server components. This paper examines the issue of security and server compromise more broadly. It summarizes key elements of Wickr’s security architecture that provide resilience to back-end server compromise and discusses the event in terms of actual attacker capabilities, or real-world impact.

Goals of the Attacker

To understand what an attacker can do with a Wickr server compromise , we need to understand the role of the server in Wickr architecture and consider the value of the data contained in back end components and databases. The Wickr server plays a key role in message delivery in support of both synchronous and asynchronous communication. It also provides centralized user directory services, permission sets, and profile and setting synchronization.

Attacks attempting to exploit the Wickr server can be generally categorized as follows:

• Attacks aimed at message security, or accessing plaintext message content;
• Attacks aimed at information and metadata, or collecting and weaponizing sensitive information about the system or its users;
• Attacks aimed at availability, or the destruction of data.

We discuss each type of attack in the sections that follow.

Message security

By compromising the server, the attacker gains access to encrypted messages as well as public ephemeral key pools . However, the messages are encrypted end-to-end and both the encrypted messages and keys in the key pools are authenticated end-to-end. This means that attackers have no ability to read or modify encrypted messages as they pass through the server and they cannot manipulate the key pools to execute man in the middle attacks.

With these protections in place, attackers hoping to gain access to message content must seek to take control of a Wickr identity. Wickr identities are rooted in asymmetric key pairs that are used to digitally sign and verify data. Trust is established by verifying the signature chain from a given object or cryptographic component to the root identity, or user (e.g., message to app, app to user).

To produce an authentic key (or message), an attacker would need to do one of the following:

1.  Obtain the private component of a user’s identity key, which could be used to authenticate Wickr apps logged into the account.

2.  Obtain the private component of an app’s identity key, which could be used to produce authentic ephemeral messaging keys and authenticate messages sent from the app.

3.  Trick a user into accepting a fake identity key for a target user, which would have the same effect as obtaining the user’s existing identity key.

The private components of app identity keys are secured in an encrypted client-side data store and out of reach of a server-side attacker. The public components are stored on the server, but are signed by the user’s (private) identity key, protecting them from tampering. Tricking users into accepting fake identity keys is more of a social engineering attack than technical attack and has little to do with a server-side foothold . Therefore, the server-side attacker’s ability to compromise a source of authenticity – and really their only technical avenue of attack to impact message security – comes down to their ability to compromise a user’s identity key.

For various reasons related mainly to system usability, user identity keys are stored on the Wickr server and secured with strong symmetric encryption. Protecting this data is ultimately a 256-bit key that is a strong cryptographic derivative of the user’s password.  This key is never stored or sent to the server, so an attacker attempting to compromise a user’s identity key would need to perform a password guessing attack against the stored version using a password derivative-generating algorithm that is specifically designed to make the process as resource and time consuming as possible. For non-trivial passwords, we could expect this process to take many years to even many thousands or millions of years if the user simply chooses a quality password of as little as 8 characters in length. To compromise multiple accounts, the attacker would need to expend the same effort again and again. This level of protection means server-side attacks against user identity keys are infeasible against all but the weakest accounts. See Wickr’s White Paper on Password Protection.

Information and metadata

With control of the Wickr server, the attacker has access to any information the service has about its users. In designing for this threat, Wickr limits the amount of user information we store to that which is minimally necessary to provide quality service. The following is a listing of the user account information available to Wickr services at the time of this writing:

Wickr Me:

• Date an account was created
• Type of device(s) on which such account was used (e.g., iOS, Android)
• Date of last use
• Total number of sent/received messages
• Number of external ID’s (phone numbers) connected to the account (not the plaintext external IDs themselves)
• Limited records of recent changes to account settings (e.g., adding or removing a device; does not include message content or routing and delivery information)
• Wickr version number

AWS Wickr:

• AWS Wickr ID (email address)
• Network affiliation
• Phone number, if provided by network administrator as a second form of authentication
• Date an account was created
• Type of device(s) on which an account was used
• Date of last use
• Total number of sent/received messages
• Number of external ID’s (phone numbers) connected to the account (not the plaintext external IDs themselves)
• Limited records of recent changes to account settings (e.g., adding or removing a device; does not include message content or routing and delivery information)
• Wickr version number
• Payment-related information
• Network settings including limited records of recent changes to network settings (e.g., enabling or disabling federation)

Wickr Enterprise (customer-controlled deployment):

• Wickr Enterprise ID (handle)
• Network affiliation
• Date an account was created
• Type of device(s) on which an account was used
• Date of last use
• Total number of sent/received messages
• Limited records of recent changes to account settings (e.g., adding or removing a device; does not include message content or routing and delivery information)
• Wickr version number
• Network settings including limited records of recent changes to network settings (e.g., enabling or disabling federation)

The above would therefore be at risk of disclosure in the event of a server compromise. Our legal process guidelines and privacy policy contain more detailed discussions on how we limit the collection and use of user information on our platform.

Control of the server also provides an attacker the ability to collect information and metadata that the service ignores. The two best examples of this in Wickr are client IP addresses and message tracking.

Wickr as a service is entirely uninterested in the IP address of Wickr clients. We don’t record them in standard configuration application logs or store them in user records. They are, however, available to certain components of the back-end infrastructure, and assuming the attacker controls the right component and conducts the right traffic and correlation analysis, this information would be at risk.

Wickr is also uninterested in who is communicating with whom on the network. We don’t record this information in standard configuration application logs. However, assuming the attacker invests a sufficient amount of time and effort in the process, the number, times, types of messages sent and received, and source and recipient Wickr IDs would be at risk. Plaintext Wickr IDs are not available in Wickr Me data stores, so this type of analysis would be far more difficult (though not impossible) to do in Wickr Me.

Availability

While perhaps not the most interesting form of attack one could imagine against a secure messaging service, attacks targeting availability of services have very real likelihoods and fairly obvious impacts. There is not a lot to discuss on this topic in this document other than to acknowledge the risk, but an attacker with control of Wickr servers would have the power to disable services and delete data, whether to simply cause chaos or deny service to legitimate users.

Summary

We hope this paper was informative for customers who wish to understand the real world impact of a Wickr server breach. In sum, such an event if exploited by a capable adversary would potentially put the following at risk:

1.     The security of future messages of accounts with weak passwords.

2.     The confidentiality of limited account information and metadata.

3.     The availability of services.

Recommendations

Choose quality passwords.

If quality passwords are used, a Wickr server compromise (known or unknown) may be considered a low or no impact event.

Consider periodic rekeying.

Periodically creating a new key pair and re-verifying with others (e.g., annually, semi-annually) can further reduce the risk of a successful password guessing attack to compromise a user’s identity key. It is also an effective method of rehabilitating a user account that you believe has already been compromised via password guessing or client-side compromise. Users can rekey their account by completing the ‘Forgot Password’ flow in AWS Wickr and Wickr Enterprise or creating a new ID in Wickr Me.