DistriNet Research Group 

KU Leuven

Dept. Computer Science 

Celestijnenlaan 200A (postbox 2402) 

200A B-3001 Heverlee BELGIUM 

  • White Facebook Icon
  • White Twitter Icon

© 2020  DistriNet KU Leuven

 

Non-repudiation

In general

Not being able to deny a claim.

The attacker can thus prove a user knows, has done or has said something. He can gather evidence to counter the claims of the repudiating party.

Typical non-repudiation examples exist in the context of anonymous online voting systems, and whistleblowing systems where plausible deniability is required.

Note that this threat is actually a security goal, as for certain systems (e.g. systems where payments are involved) non-repudiation is an important asset. This should however not result in any conflicts, as systems that require non-repudiation as a security goal, will not need plausible deniability for the same data/ subsystem.

Consequences

  • Accountability: when a person is not able to repudiate an action or piece of information, he can be held accountable. (e.g. a whistleblower can be prosecuted)

Impacted by

  • Identifiability: if data are identifiable, it will be hard to repudiate (-)

 

Non-repudiation of data flow

 
non-repudiation of data flow (LINDDUN)

Tree in general

Non-repudiation of a data flow implies that the subject cannot deny having sent a message. This can occur when data sources of flows are insufficiently obfuscated, when weak deniable encryption, weak MACs, or weak off-the-record messaging are used.

Leaf nodes explanation

Four types of threats can lead to non-repudiation of data flow.

Insufficient data sources or data flows obfuscation (NR_DF1)

The first type is insufficient obfuscation for data sources or data flows, which means that the attacker can gain access to at least part of the data flow or data source. This can occur in a number of cases, for example, there is no automatic replay of broadcasts (NR_DF5), such that the sender of a file is sufficiently distinguishable from those who are merely relaying it. Another example is when a complete decrypted log of all network connections to and from a user's computer is disclosed (NR_DF7), resulting in the disclosure of the origin of data flow. The final examples are that there is insufficient protection against censors (NR_DF6) or insufficient obfuscation of data extensions (NR_DF8), such that operators or users of the network are able to know where the data comes from.

No or weak deniable encryption (NR_DF2)

The second type of threat is that little or a weak deniable encryption technique is used to protect data flow. One possible attack path is to prove data are encrypted (NR_DF9), either the encrypter proves the data are obviously an encryption (NR_DF15) or colluding users prove together that the data are encrypted (NR_16).

The second attack path is to prove data can be decrypted to a valid plain text (NR_DF11), which can occur when the encrypter decrypts the file (NR_DF17) or colluding users can cooperate and show the decrypted message (NR_DF18).

The third attack path shows that all private keys are disclosed (NR_DF10), which clearly enables decryption.

Finally, also cryptanalysis (NR_DF12) is possible to attack the used encryption scheme.

No or weak MACs used (NR_DF3)

The third type of threat is the lack of strong message authentication codes (MAC) (NR_DF3) to ensure integrity of data flow content, such that an attacker can forge authentic looking messages and pretend that a certain data flow comes from a subject.

No or weak off-the-record messaging (NR_DF4)

The final precondition indicates that there is little or a weak off-the-record messaging (OTR) (NR_DF4) used, such that in a conversation it is not possible to provide both deniability for the conversation participants and confidentiality of conversations content at the same time. Possible attack paths include replaying of previous transferred messages (NR_DF13), and the use of signatures (NR_DF14) to demonstrate communication events, participants and communication content.

Non-repudiation of data store

LINDDUN non-repudiation of data store

Tree in general

Non-repudiation in the data store refers to the threat where a subject is not able to deny certain data in the database. This can be either data he has stored himself or data that others have stored about the subject.

Leaf nodes explanation

No or weak deniable encryption (NR_DS1)

When little or a weak deniable encryption (NR_DS1) is used to protect the data, it can be proven that data are an encryption (NR_DS4) or can be decrypted to a valid plaintext (NR_DS5).

Weak access control to the database (NR_DS2)

When there is weak access control to the database (NR_DS2), the stored data are no longer deniable. This can occur when there is a threat of information disclosure at the data store (ID_DS).

Person wanting deniability cannot edit database(NR_DS3)

If subjects want deniability but are not able to edit data in the database (NR_DS3) to cover their tracks, their data becomes non-repudiable. It can be either impossible to remove or alter the user's own data (NR_DS6) or impossible to remove or alter someone else's data concerning the user himself (NR_DS7).

Note that this threat does not apply solely to a database that can be directly accessed by the user. It applies to all collected data. For example, Google has to implement the 'right to be forgotten' which allows data subjects to request removal of personal information from Google's search index if the links are inadequate, irrelevant or no longer relevant, or excessive in relation to the purposes for which they were processed [1].

[1] This is actually an extension of the unawareness threat regarding data reviewal (U_5 in the unawareness tree). Not only should a subject be aware of the data that is collected about him (U), he should also be able to revoke it (NR).

database contains identifiable data, like an identity management database does, the entire dataset becomes identifiable

 

Non-repudiation of process

LINDDUN non-repudiation of data store

Tree in general

Non-repudiation of a process implies that it cannot be denied that the process has been run. It is however a very rare threat.

Leaf nodes explanation

Non-repudiation of a process can be achieved in two ways.

Either the process loses its confidentiality and information disclosure attacks at the process (ID_P) are possible, or the process uses a secure log (NR_P1) to create an overview of all actions, which can evidently be traced back to the user.