Home > Articles > Security > Network Security

  • Print
  • + Share This
This chapter is from the book

3.4 Non-repudiation

Non-repudiation protocols are used to enable agents to send and receive messages, and provide them each with evidence so that neither of them can successfully deny at a later time that the message was transmitted or received. Participants aim to collect evidence to prove that the other party did send or receive the message (as appropriate). Non-repudiation evidence can be generated for one party or for both parties. A protocol designed to achieve this is generally required to provide the property of correctness of the evidence: that the evidence really is strong enough to guarantee what the holder requires of it. Evidence is often in the form of signed messages, which provide guarantees concerning their originator.

In some cases where evidence is provided to both parties, the protocol might also aim to provide fairness: that no party should be able to reach a point where they have the evidence or the message that they require without the other party also having their required evidence. Fairness is not required for non-repudiation, but it may be desirable in some cases from the point of view of the participants.

In contrast to authentication and key-exchange protocols, non-repudiation protocols are not concerned with communication in the presence of an intruder between two parties who trust each other. Instead they are used when a communication is required between two agents who require protection from each other and who do not entirely trust each other to behave honourably in the future. They are typically proposed in the context of a passive communication medium that cannot be manipulated by either party or by other agents, but which may nevertheless have some unreliable behaviour.

In analysis, the system must be modelled from the point of view of the environment of the system that would be used to arbitrate in the case of a dispute. Correctness is concerned with whether the environment, which cannot know a priori which agents are honest, must accept evidence as guaranteeing that the message was sent. This concerns the nature of evidence: an agent might himself know that a message was sent, and yet not be in a position to prove this to anyone else.

This means that for the modelling and analysis of non-repudiation protocols, a different threat model must be used. In deciding whether a particular message has been sent, neither of the participants can be trusted to behave according to the protocol, and the possibility that either or both of them do not behave honestly must be allowed. However, it will generally have to be assumed that trusted third parties (which are sometimes used in non-repudiation protocols) do behave according to the protocol.

Although the threat model is different, non-repudiation properties are expressed in a similar way to authentication: that the occurrence of some event guarantees that some previous message was sent. The provision of a certain piece of evidence should guarantee that a particular message was previously sent by a particular party.

A non-repudiation protocol is thus concerned with the creation of evidence for the parties involved. Correctness will be concerned with the suitability of the evidence, and the analysis (given the altered threat model) will have to take into account the fact that the participants might not behave in accordance with the protocol. These parties are therefore modelled almost as the intruder is for secrecy and authentication analysis: that they can behave in any way in line with their capabilities, apart from some elementary security requirements, for example that they do not give away their private keys. Their capabilities with these assumptions built in will be encapsulated into a relation ⊢a, which is essentially the same as ⊢ except that a’s private keys cannot appear as part of any fact on the right-hand side: we assume that the agent will never give out his own private key in any form.

The behaviour of an arbitrary user of the network is therefore described by the CSP process description Agenta:

03fig47.gif


An agent with information S is able to send any data in S, and can also present any such information as evidence. He can also receive any message m (which will increase S) from the medium.

Depending on the context of the protocol, the medium might be considered to be under the control of an intruder, or it may be considered simply to be an unreliable medium. Which of these models to use depends on the threat model that is deemed to be realistic: whether we will be concerned with the possibility that evidence is correct in the presence of an external intruder who might have interfered with the protocol, or whether the medium is not considered to be so actively hostile but simply unreliable. Furthermore, the unreliability of the medium (or the power of participating agents over the medium) might conceivably make a difference, particularly on issues such as whether messages can be delivered to the wrong address.

The system is then described in the usual way, as follows:

03fig48.gif


The initial knowledge of the agents IKa will include their own private keys, and possibly keys shared with other agents. The initial knowledge of the medium will depend on the model of the medium. If it is simply an unreliable medium then it will simply hold messages that are passed to it, and hence its initial knowledge will be empty. However, if the medium can behave as a more active intruder then there may be some specific initial information, such as the private keys of compromised agents.

The non-repudiation property can require that occurrence of evidence.a.m (presented to the environment) provides a guarantee that some other message m′ must previously have been produced by b. This may be expressed as follows:

03fig49.gif


Since b cannot be relied upon to behave in accordance with the protocol, the message m′ might not have been issued by b directly as a complete message. However, m should still provide evidence that m′ was somehow issued by b, even if it was in a different form than the protocol expects.

For example, if a has the message {m}Private_Key(b) which has been signed by b using a private key unavailable to any agent other than b, then a is in possession of evidence that b issued m in some sense. However, it may have been sent as a component of a larger message or under further encryption, so the fact{m}Private_Key(b) might not have been transmitted as a message itself. The notation b sent m′ will be used to mean that m′ was transmitted by b, possibly as a component of a larger message (and not necessarily to the agent presenting the evidence):

03fig50.gif


where the contains relation is defined as follows: For all messages m, m′, and m″, and keys k:

  • m contains m

  • m′ contains mm″.m′ contains m

  • m′ contains mm′.m″ contains m

  • m′ contains mk(m′) contains m

In the face of the threat model we are considering, this appears to be the strongest property that can be expressed for a non-repudiation protocol. In some sense if the message sent by b is going to be taken as evidence then it is incumbent upon b to issue it with care, and it would be unusual in practice for b to transmit it in any other form (though he should take care to ensure this does not occur by accident).

Example: the Zhou-Gollmann protocol

We will consider the modelling of a particular non-repudiation protocol. In fact this makes use of some additional features that require extensions to the model described above. The aim is for a to send a message m to b, and for the parties to obtain evidence that the message was sent and received. This protocol also aims to achieve fairness.

The message m is transferred in two stages: an encrypted form is first sent directly to b under some key k, and after a has received evidence of receipt from b the key k itself is sent via a trusted server. The server makes the key available via ftp, and both a and b have the responsibility to retrieve the key and the evidence that it was deposited by a.

Agent b should not be able to extract m until both of these messages have been received.

A cut-down version of the protocol, with the unsigned parts of the message omitted, is described as follows:

03fig51.gif


Zhou and Gollmann explain the elements of the protocol as follows:

  • a: originator of the non-repudiation exchange.

  • b: recipient of the non-repudiation exchange.

  • j: on-line trusted server providing network services accessible to the public.

  • m: message that is to be sent from a to b.

  • c: commitment (ciphertext) for message m, e.g. m encrypted under a key k. The point is that c in itself is not enough to identify the message m, but that c together with k is.

  • k: message key defined by a.

  • l is a label used to identify a particular protocol run. It should be unique to a single protocol run.

  • fNRO, fNRR, fSUB and fCON are flags used to identify the step of the protocol in which a particular message was generated.

  • SKi is a private signature key known only to its owner i; and SKj is the server’s private signature key.

The steps of the protocol are explained as follows:

  • 1 With the first message, a sends a signed combination of c = k(m), a label l, and the recipient’s name b. b will use this as evidence that k(m) was sent in a run identified with l.

  • 2 b responds with a signed record that c has been received in run l. This will provide evidence for a that k(m) was received.

  • 3 a then sends the key k to the trusted server together with the label l.If a tries to cheat by sending the wrong key, then he will not obtain the evidence he requires, since k(m) and k′ will not provide evidence that m was sent.

  • 4&5 Each of a and b can retrieve, by means of an ftp-get, a signed record from s that the key k associated with protocol run l has been deposited. Responsibility for retrieving this information rests with the agents themselves, to nullify a possible future claim that ‘the message was never received’. Thus both a and b can obtain evidence that the key k was made available to b.

The server only needs to handle relatively small messages, and make them available by ftp, so this protocol is appropriate even if the messages themselves are extremely large, since the server never has to handle them directly.

At the end of the protocol run, if a wishes to prove that the message has been received, he presents 03fig52.gif the first piece of evidence confirms that b received c, and the second piece confirms that the key was deposited with the server, which means that b has access to it, and hence to the message. The label l in both pieces of evidence connects the two items k and c as being associated with the same protocol run. This reasoning is really concerned with two pieces of evidence, and is thus captured as two requirements on the system:

03fig53.gif


The non-repudiation of receipt property NRR(tr) is taken as the conjunction of these ] two implications. If the system provides both of these properties, then a has only to present his evidence to prove that b did indeed have access to the message m. The honest operation of the server means that a need only present evidence that the server received the correct message. The system then guarantees that this information is also available to b.

If b wishes to prove that the message was sent by a, he presents both pieces of evidence SKa(fNRO.b.l.c) and SKj(fCON.a.b.l.k): the first provides evidence that c was sent, and the second provides evidence that k was also sent, to the server. This treatment of evidence is again expressed as two trace requirements:

03fig54.gif


The non-repudiation of origin property NRO(tr) is defined as the conjunction of these two trace properties.

The CSP model of the system will have to include at least the two participants in the protocol and the server. It is also reasonable to allow the presence of other agents who are potential protocol participants, since the protocol is expected to be correct even in the presence of other users of the network. The ftp connection can be modelled as another channel ftp directly between the server and the participants. In fact this does not make any difference to correctness with respect to the properties above, but it justifies the informal argument that messages are available to the agents once they have arrived at the server, and underpins the claim that the properties above are appropriate.

The entire network is the parallel combination of these components:

03fig55.gif


This is illustrated in Figure 3.8.

03fig58.gifFigure 3.8. Network for the Zhou-Gollmann non-repudiation protocol

The description of the participating agents is extended to permit receipt of facts along the ftp channel from Jeeves:

03fig56.gif


The server described by process Server accepts signed messages of the form of step 3 of the protocol, and makes them available via ftp. It is assumed that the server acts in accordance with its role in the protocol. It is therefore modelled as follows:

03fig57.gif


The server guarantees that any messages retrieved from it via ftp correspond to receipt of an appropriately signed fSUB message in accordance with the protocol.

The correctness requirements on the entire system are then

03fig59.gif


and

03fig60.gif


The protocol itself is not modelled explicitly within CSP. The descriptions of the agents allow correct execution of the protocol as possible behaviour. If the system meets these properties, then it proves that the evidence is sufficient to provide the guarantees we require, in the context of the server. The protocol can be seen as a pragmatic suggestion for how the participants might obtain the evidence they require, but the security property of the protocol rests more on the nature of the evidence than on the participants following the protocol itself.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020