Non-repudiation of Forwarding

Traceability of Conﬁdential Data Via Multiple Recipients

Rainer Schick and Christoph Ruland

Chair for Data Communications Systems, University of Siegen, Hoelderlinstr. 3, Siegen, Germany

Keywords:

Non-repudiation, Data Leakage Protection, Security Service, Data Tracking, Evidence Generation.

Abstract:

Nowadays, it can be assumed that valuable private data can be securely transmitted from one sender to one (or

more) recipients. An unsolved problem following the transmission is addressed by this paper. The sender of

some conﬁdential information does not know what happens with the data after the transmission. If the message

appears in a place it should not, the originator does not know who published it unauthorized. In order to solve

this problem, this paper introduces a new non-repudiation service that allows tracking the way of protected

data via several recipients.

1 INTRODUCTION

As far as conﬁdential data is concerned, these data can

be protected against unauthorized access in different

ways. But what happens if allegedly trustworthy re-

ceivers misbehave? How to ﬁnd out who is the data

leak? These questions are often neglected in compa-

nies and other institutions. For the originator of sen-

sitive private data it would be best if there would be a

new security service that provides traceability of con-

ﬁdential information.

The new service deals with the topics of Endpoint

Security and Data Leakage Protection (Scheidemann,

2008). Actually, one of the largest problems of com-

panies is the unauthorized use of private devices by

their employees. Large amount of data can be stored

on such insecure devices and the damage may be huge

if such a device gets lost. The new non-repudiation of

forwarding service (NRFS) introduced in this paper

collects so-called tracking data from multiple recipi-

ents and provides traceability of protected data. The

tracking data prove the forwarding of conﬁdential in-

formation and are updated for each transmission. If

a dispute arises, these data are used to generate evi-

dence. The conﬂict resolution after the evidence gen-

eration phase is out of scope of the NRFS.

After this introduction, related work are ﬁgured

out in the next chapter. Chapter 3 then describes

the basic idea of non-repudiation services and ﬁgures

out the innovations and advantages of the NRFS. The

Data Tracking Protocol (DTP) introduced in chapter

4 is designed to realize the NRFS. The protocol en-

sures that the tracking data are protected against tar-

geted manipulations using a security module. Finally,

in chapter 5 some conclusions are presented and an

outlook to future work is given.

2 RELATED WORK

The ISO/IEC 13888 standards describe 8 different

non-repudiation services (ISO/IEC 13888-1, 2009;

ISO/IEC 13888-2, 2010; ISO/IEC 13888-3, 2009).

General information about non-repudiation services

are described in ISO 13888-1. Examples for sym-

metric techniques are given in part 2, asymmetric

techniques in part 3. These services provide protec-

tion against an individual falsely denying the involve-

ment in a particular action or event. For example,

the sender can request a token which proves the re-

ceipt by the designated recipient. The recipient in turn

requests a token which proves the forwarding to the

sender. The goal of the NRFS is to prove the action

of forwarding by allegedly trusted users.

Non-repudiation services and their underlying

protocols usually should be fair (Zhou and Gollmann,

1996; Kremer et al., 2002), so that no party gets an

advantage over another party. The NRFS does not

exchange token between sender and receiver, so the

aspect of fairness does not need to be considered.

Regarding the reliability of the NRFS, false posi-

tives must be prevented under all circumstances. No

manipulation should lead to a user falsely being sus-

pected. Manipulations that prevent the expose of an

387

Schick R. and Ruland C..

Non-repudiation of Forwarding - Traceability of Conﬁdential Data Via Multiple Recipients.

DOI: 10.5220/0004053303870390

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 387-390

ISBN: 978-989-8565-24-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

attacker should also be prevented, if possible.

There exist other approaches to provide traceabil-

ity of data. One is digital watermarking (Liu et al.,

2005; Wang et al., 2001; Cox et al., 2008). Dig-

ital watermarks support copyright holders to track

data leaks if an unauthorized copy is found. Water-

marks can be embedded visible or invisible and have

to cope with different problems: The embedding ca-

pacity is limited in relation to the size of its carrier

(Barg et al., 2003) and the embedding algorithms de-

pend on the ﬁle format. Another approach is Digi-

tal Rights Management (DRM). This technique is of-

ten used to preventunauthorized copies of multimedia

data. This is done by installing proprietary software

and by using online activation mechanisms. DRM

is considered controversially, and many experts claim

that unauthorized copies cannot be prevented (INDI-

CARE Project, 2006; Schneier, 2001).

3 NON-REPUDIATION OF

FORWARDING

3.1 Non-repudiation Services

The goal of non-repudiation services is to protect

the parties involved in a transaction against the other

party falsely denying the participation in a particular

event or action. For example, a sender of a message M

can generate evidence for sending it. The recipient in

turn generates evidence of the corresponding receipt.

These evidences are called non-repudiation token.

(Zhou and Gollmann, 1996) and (ISO/IEC 10181-

4, 1997) divide non-repudiation services into four,

(Ford, 1994) and (RFC 4949, 2007) into six phases.

The following list refers to the compact representa-

tion as shown in (ISO/IEC 10181-4, 1997):

1. Evidence generation: The critical action occurs

and evidence is generated.

2. This phase includes the transfer, storage and re-

quest of the evidence.

3. The evidence is veriﬁed by a trusted authority.

4. Dispute resolution: Evidence is retrieved from

storage, presented and again veriﬁed to resolve the

dispute.

If symmetric techniques are used, the token must nec-

essarily be veriﬁed by a Trusted Third Party (TTP) in

case of a dispute. Using asymmetric techniques, the

TTP is not mandatory. Nevertheless, the authenticity

of the applied public keys must be guaranteed. Non-

repudiation policies may enforce that only TTPs are

allowed to generate the token. Usually, a URL to the

used policy is part of the generated token. A non-

repudiation service must permit a trusted authority to

verify if a given signature was applied to given data.

This authority checks if the private signature key cor-

responds to a given valid certiﬁcate.

In contrast to existing non-repudiation services,

the NRFS collects evidences for multiple transac-

tions. Each sender and recipient adds certain informa-

tion to the protected data (Schick and Ruland, 2011b;

Schick and Ruland, 2011a). Spoken clearly, for each

action unique tracking data are added to the conﬁden-

tial message. That is, the NRFS allows incremental

updates of the tracking data for each forwarding and

thus tracking the whole way of data from the origina-

tor to the last recipient.

3.2 Requirements of the NRFS

The main goal of the NRFS is to provide traceability

for conﬁdential data over multiple recipients. Addi-

tionally, the originator must be able to prove to be the

source of the information and the protected message

must not be accessible by the recipient unless his or

her unique tracking data are indelible added. Finally,

the plaintext data output to the recipient must be ac-

companied by unique tracking data. These tracking

data should not be erasable. At least any manipula-

tion of these data must be recognized reliably.

To achieve these requirements, a security module is

needed to realize the DTP. This module is mandatory

for different reasons: It provides access control and

ensures that the conﬁdential message is output to the

user only if the embedded tracking data are authentic.

Most importantly, the private and secret keys required

by the DTP can be securely stored, without even the

owner of the module knowing the keys. Speciﬁed

Protocol Data Units (PDUs) are transmitted between

the security modules of the users.

3.3 Service Description

The NRFS implies a closed group of recipients (e.g.

a company network), so that the TTP may be rep-

resented by the initial sender O . The TTP should

not be involved in each transaction, so that the role

of the TTP is off-line. Digital signatures and trans-

action timestamps are used to generate and provide

the evidence. Thus, the NRFS is an asymmetric non-

repudiation service. Table 1 summarizes the service

descriptions and shows that the NRFS consists of two

different data processing parts. The security module

processes the encrypted data and handles the private

and secret keys of its owner, while the digital water-

mark will be embedded into the plaintext message M.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

388

Table 1: Description of the non-repudiation of forwarding service.

SECURITY MODULE WATERMARK

CLASS OF NRS: Non-Repudiation of Forwarding Non-Repudiation of Forwarding

ROLE OF TTP: Off-line Off-line

TYPE OF EVIDENCE: Digital Signature, Timestamp Digital Signature, Timestamp

GOAL OF EVIDENCE: Proof of forwarding to all sender Proof of last authorized receipt

USER OF SERVICE: Data originator, all recipients Data originator

CONCERNED USER: All sender Last authorized recipient

4 DATA TRACKING PROTOCOL

4.1 Goals of the Data Tracking Protocol

The DTP is designed to fulﬁll the requirements spec-

iﬁed in chapter 3.2 und thus to realize the non-

repudiation of forwarding service. The basic ideas

of the DTP have been described in (Schick and Ru-

land, 2011b; Schick and Ruland, 2011a). Figure 1

shows the abstraction of the NRFS from the user’s

point of view. The user does not need to have knowl-

edge about the underlying protocol. Instead, certain

data are input as parametersinto the service primitives

provided by the security module through the service

access points (SAP). Finally, certain data are output

to the user. The communication between two service

users is realized by the DTP.

The use of a Public-Key Infrastructure (PKI) is a

basic requirement of the DTP and the existence of an

appropriatePKI is assumed for the DTP. This includes

the veriﬁcation of digital certiﬁcates, reconciliation

with a Certiﬁcate Revocation List (CRL) and check-

ing the nonRepudiation bit in the keyUsage extension

of X.509v3 certiﬁcates (RFC 5280, 2008).

Different functions (called service primitives)must be

provided by the security module. Users must be able

to initialize and conﬁgure the service, send and re-

ceive data and ﬁnally generate evidences in case of a

dispute. The functionality of the protocol and each

function provided by the security module are brieﬂy

described in the following.

4.2 Tracking Data

The tracking data are used to track the way of mes-

sage M if a dispute arises. These data consist of

unique identiﬁers which distinguish the participating

users and the protected message M. The size of the

Non-Repudiation

of Forwarding

service

primitives

SAP

service

user

service

user

security

module

security

module

Data Tracking Protocol

SAP

Figure 1: The different layers from the user’s point of view.

tracking data should be kept as small as possible be-

cause of the security module. On the contrary, these

data are used to generate evidence, so they have to be

both unique and provableauthentic. This is a common

problem in information security - security increases

overhead and complexity. The tracking data must be

protected from several attacks. This includes protec-

tion from targeted manipulations, trafﬁc ﬂow analyses

and privacy aspects (concerning the user identifers).

More detailed descriptions of the protection mecha-

nisms will be part of future work.

4.3 Functions of the Security Module

With the security module, the required private and se-

cret keys must be generated and stored within a se-

cure environment. The owner of the module must not

have access to these keys, otherwise he or she would

be able to tamper data. Additionally, the conﬁden-

tial message M must not be output to the receiver if

any manipulation is detected or if M (or its originator)

is not provable authentic. If so, the security module

has to stop data processing and signalize an informa-

tive error message. Thirdly, the tracking data must be

added to M before the receiver gets access to it. The

authenticating signatures must also be generated and

veriﬁed by the security module. Hence, the module

Non-repudiationofForwarding-TraceabilityofConfidentialDataViaMultipleRecipients

389

must provide the following functions:

1. Initialize. Lets the originator conﬁgure the DTP

and prepare the data for the protocol. The required

keys are also generated by this function.

2. Send. If data should be forwarded to the next au-

thorized receiver, this function must be used. It

sets up a secure communication channel and sends

encrypted data.

3. Receive. Processes the received encrypted data.

If the data are in good condition, the watermarked

plaintext and encrypted storage data are output.

4. Evidence-TD. Generates the non-repudiation to-

ken based on the tracking data accompanying the

protected data containing M.

5. Evidence-WM. Generates the token based on the

digital watermark which has been inserted into the

plaintext message.

5 CONCLUSIONS

With the non-repudiation of forwarding service, con-

ﬁdential data can be tracked via multiple recipients.

Evidence can be generated to prove the whole way

of protected data. The service is split into two parts:

The ﬁrst part relies on a security module and the sec-

ond part inserts digital watermarks into the plaintext

that output to the recipient.

The data processing part provides a high level of se-

curity. The user is not able to access the conﬁdential

data unless the security module accepts the received

data as valid. The security services of peer entity au-

thentication, non-repudiation of origin, data integrity

and access control are provided. The user is not in

possession of any private or secret key. Instead, these

keys are managed by the security module.

In future work, the key management must be de-

scribed and information about secure key storage and

distribution must be given. Moreover, legal aspects

of the NRFS should be analyzed. The requirements

that are necessary to make the non-repudiation token

valid evidences must be pointed out. Due to the re-

quired computational power of digital watermarking

algorithms, an appropriate security module must be

found. Finally, that module should provide the ser-

vice primitives described in this paper.

ACKNOWLEDGEMENTS

This work is funded by the German Research Foun-

dation (DFG) as part of the research training group

GRK 1564 - ’Imaging New Modalities’.

REFERENCES

Barg, E., Blakley, G. R., and Kabatiansky, G. A. (2003).

Digital ﬁngerprinting codes: Problem statements,

constructions, identiﬁcation of traitors. In IEEE

Transactions on Information Theory Vol. 49, pages

852–865.

Cox, I. J., Miller, M. L., Bloom, J. A., Fridrich, J.,

and Kalker, T. (2008). Digital Watermarking and

Steganography. Elsevier, second edition edition.

Ford, W. (1994). Computer Communications Security:

Principles, Standard Protocols and Techniques. Pren-

tice Hall, ﬁrst edition edition.

INDICARE Project (2006). Consumer’s guide to digital

rights management.

ISO/IEC 10181-4 (1997). Information technology - Open

Systems Interconnection - Security frameworks for

open systems: Non-repudiation framework. Interna-

tional Organization for Standardization.

ISO/IEC 13888-1 (2009). Information technology - Secu-

rity techniques - Non-repudiation - Part 1: General.

International Organization for Standardization.

ISO/IEC 13888-2 (2010). Information technology - Security

techniques - Non-repudiation - Part 2: Mechanisms

using symmetric techniques. International Organiza-

tion for Standardization.

ISO/IEC 13888-3 (2009). Information technology - Security

techniques - Non-repudiation - Part 3: Mechanisms

using asymmetric techniques. International Organiza-

tion for Standardization.

Kremer, S., Markowitch, O., and Zhou, J. (2002). An inten-

sive survey of fair non-repudiation protocols. In Com-

puter Communications Vol. 25, pages 1606–1621.

Liu, R., Trappe, W., Wang, J., Wu, M., and Zhao, H. (2005).

Multimedia Fingerprinting Forensics for Traitor Trac-

ing. Hindawi Publishing Corporation.

RFC 4949 (2007). Internet Security Glossary, Version 2.

Network Working Group.

RFC 5280 (2008). Internet X.509 Public Key Infrastruc-

ture Certiﬁcate and Certiﬁcate Revocation List (CRL)

Proﬁle. Network Working Group.

Scheidemann, V. (2008). Endpoint security: Data loss pre-

vention.

Schick, R. and Ruland, C. (2011a). Data leakage tracking

- non-repudiation of forwarding. In Communications

in Computer and Information Science Vol. 251, pages

163–173.

Schick, R. and Ruland, C. (2011b). Document tracking - on

the way to a new security service. In IEEE Conference

on Network and Information Systems Security, pages

89–93.

Schneier, B. (2001). The futility of digital copy prevention.

Wang, Y., Doherty, J. F., and van Dyck, R. (2001). A water-

marking algorithm for ﬁngerprinting intelligence im-

ages. In John Hopkins University, pages 21–24.

Zhou, J. and Gollmann, D. (1996). A fair non-repudiation

protocol. In IEEE Symposium on Security and Pri-

vacy, pages 55–61.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

390