2
$\begingroup$

I'm writing a document and I am making an important statement in it, which may be used for strategic decision regarding data-management (possibly from never handling sensitive information online to allowing some to be). I am certain of that statement, however I would like encryption specialists to confirm, infirm or precise it. This is the statement:

Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter (from an access to the data perspective) if the account on the server is hacked. In that case the real protection for the data is the encryption, not the server itself, although it does act as an additional layer of security.

Context: The data is encrypted on a local device and submitted (encrypted) on to the application on the server. It is then downloaded by users (still encrypted) to be decrypted locally using the key. We are talking about AES 256 bits encryption using CFB. The statement does not concern data management by users (e.g. their handling of the key, as it does state that it assumes this is done properly) and does not concern the mobile devices used to created/encrypt/submit the data (this is addressed separately).

I am aiming at being as precise as possible (e.g. I don't want it to be generic hog-wash more aimed at protecting the writer than helping), but I want to be certain of what is written.

So the question is: Is the statement true in the context defined? If it is not or should be nuanced/modified, what should I change?

EDIT: (The reworded statement according to provided answer below):

Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter from a data confidentiality perspective if the account is hacked, although in that case data integrity is not guaranteed. The real protection for confidentiality of the data is the encryption, not the server.

$\endgroup$
  • $\begingroup$ Slightly off topic: why CFB? That's not a common mode of encryption (anymore). AEAD ciphers such as GCM & EAX are all the rage now... $\endgroup$ – Maarten Bodewes Dec 13 '16 at 18:01
  • $\begingroup$ It's been there for some time (part of an application). Unless we get to a point where it can be considered unsafe, I doubt it's possible to put it as a priority on the road map. $\endgroup$ – Francky_V Dec 13 '16 at 18:04
3
$\begingroup$

Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter (from an access to the data perspective) if the account on the server is hacked. In that case the real protection for the data is the encryption, not the server itself, although it does act as an additional layer of security.

Yes and ... No.

Could you define what do you mean by access to the data perspective ? By whom ?

You need to have a clear definition of the properties you want to guarantee. In cryptography there are 3 essential properties.

confidentiality: only the authorized users can read the data (and understand it).

integrity: the users have the guarantee that the data have not been modified, or in other words only the authorized users can modify the data.

authenticity: the users have the guarantee that the data/entities are who they are (this is different from identification).

In the case you are talking about, you only implies that you are providing confidentiality but no integrity. In other word, an attacker could access the data, not be able to read it but could still modify it. Note also that the property access to the data perspective is not provided anymore to the authorized user in the case where the data have been modified.

Thus in my opinion, you should slightly improve the text to say that you don't provide the integrity in this case (or use an Authenticated Encryption Scheme). It might also be a good idea to use the vocabulary previously defined (confidentiality and integrity).

$\endgroup$
  • $\begingroup$ Great that's exactly the kind of things I am looking for. With proper vocab: I do mean mostly confidentiality (as that data can be detrimental if read). I wasn't sure about integrity (an issue but less so in my use case). $\endgroup$ – Francky_V Dec 13 '16 at 17:46
  • $\begingroup$ Integrity is usually an issue even when you think it isn't. In many real-world cryptosystems, lacking integrity often compromises confidentiality — padding oracle attacks are an example of this. Strongly consider using an authenticated encryption scheme like GCM. $\endgroup$ – Stephen Touset Dec 13 '16 at 21:03
  • $\begingroup$ Note that even using authenticated encryption does not guarantee integrity, only authenticity. You can't detect a rollback. $\endgroup$ – Gilles Dec 13 '16 at 22:28
2
$\begingroup$

I will address you first rewritten version of the text, and highlight the part that I think needs improvement:

Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter from a data confidentiality perspective if the account is hacked, although in that case data integrity is not guaranteed. The real protection for confidentiality of the data is the encryption, not the server.

The boldfaced part is strictly true, but this is a place where additional clarity would be good. In particular, I think the authenticity risks needs to be stated in terms of this question:

  • If somebody modifies the ciphertext on the server, can they fool the legitimate user into accepting it as authentic? Examples:
    • Attacks based on cipher malleability;
    • Replay or reordering attacks, or other attacks based on substituting known valid ciphertexts for each other.

Just saying that "data integrity is not guaranteed" allows for a "yes" answer to the question, because that just means that the ciphertexts that the user downloads may be different from the ones they upload, and the system doesn't provide any secure mechanism to detect this condition.

More worrisome, if you're discussing this with stakeholders who aren't familiar with cryptography or security, the term "data integrity" may in their minds connote transmission errors that lead to data loss, not malicious attacks that lead to deception. So it's apt to cause people to underestimate the risks.

I'd also add that once you start spelling out and contextualizing the lack of authenticity guarantees, you and your decision makers may just end up insisting on authenticated encryption. Why work so hard at understanding all of the possible risks of an unauthenticated system, instead of just removing them?

$\endgroup$
  • $\begingroup$ Because we do not develop the solution - we choose among existing options and decide or not to allow some data online or not. In a context where there would be little incentive to edit maliciously the data, but higher incentive to read it, it may make sense to accept some level of risks with authenticity. Also if you know who submitted and when (from other sources) you may be able to identify out of line edits/submissions. $\endgroup$ – Francky_V Dec 14 '16 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.