Seminarsonly.Com

Custom Search

>>

 

Are you interested in this topic.Then mail to us immediately to get the full report.

email :- contactv2@gmail.com

 

 

 

Custom Search

 

 

 

 

 

 

 

 

 

Multiparty Nonrepudiation : Seminar Report and PPT

 Abstract of Multiparty Nonrepudiation

Nonrepudiation is one of the fundamental security issues existing in paper-based and electronic environments. The transacting parties want to seek a fair settlement of disputes, which brings the need nonrepudiation services in their transactions. Nonrepudiation services help the transacting parties to settle possible disputes over whether a particular event or action has been taken place in a transaction. This seminar focuses on multiparty scenarios (applications like e-voting,e-bidding, etc., usually involve several parties) and provides a comprehensive overview. It discusses fundamental issues on nonrepudiation, including the types of nonrepudiation service in the direct and indirect communication model, cryptographic evidence, the roles of Trusted Third Party (TTP), non repudiation phases and requirements. It also describes the general 1-N and N-N multiparty nonrepudiation problems and their solutions. Finally, it discusses advanced solutions for two typical multiparty nonrepudiation applications, namely, multiparty certified email and multiparty contract signing.

With the explosion of Internet, electronic transactions have become more and more common. However the transactions’ security is crucial to many applications, eg. Electronic Commerce, Digital Contract Signing, Electronic Voting, and so on. The impressive growth of open networks during the last decade has given more importance to several security related problems. The nonrepudiation problem is one of them. Most cryptographic algorithms provide a means for secret and authentic communication. However, under many circumstances, the ability to repudiate messages or deny a conversation is no less important than secrecy and authenticity.

Non-repudiation services must ensure that when sender A sends some information to receiver B over a network, both sender and receiver receive evidence showing that the other party has participated in a part or the whole of this communication. The aim of a non-repudiation protocol is to provide non-repudiation of origin and non-repudiation of receipt, with respect to a given message. There are different ways to consider the exchange of the evidences. Either the recipient already knows the message before the exchange protocol starts, and he can thus refuse to run the protocol for this message, or the recipient has to send a nonrepudiation of receipt evidence, as soon as he gets to know the message. In the latter case, in many usual applications, the exchange of the message and the nonrepudiation of origin evidence against a nonrepudiation of receipt evidence has to be fair.

A nonrepudiation protocol is fair if either sender receives a nonrepudiation of receipt evidence and receiver receives the message and the corresponding non-repudiation of origin evidence or none of them obtains any valid evidence.

Fundamentals of nonrepudiation

Repudiation is one of the fundamental security issues existing in paper-based and electronic environments. Dispute of transactions is a common issue in the business world. Transacting parties want to seek a fair settlement of disputes, which brings the need nonrepudiation services in their transactions. The motivation for nonrepudiation services is not just the possibility that communicating parties may try to cheat each other. It is also the fact that no system is perfect, and that different and unexpected circumstances can arise in which two parties end up with different views of something that happened. Network failure during the protocol run is a representative example.

A basic transaction is the transferring of a message M (e.g., electronicgoods, electronic cash, or electronic contracts) from user A to user B, and represent this event with the following message flow: A → B : M . Thus, typical disputes that may arise in a basic transaction with a deadline T could be:

—A claims that it has sent M to B, while B denies having received it;

—B claims that it received M from A, while A denies sending it; and

—A claims that it sent M before T , while B denies receiving it before T .

Fair nonrepudiation can be considered as an extended fair exchange problem in which nonrepudiability is made an integral requirement of the exchange. We can find various instances of the general exchange problem in different types of commercial activities: purchase, contract signing, certified mail, or, more generally, in any barter conducted by means of digital networks. An exchange is said to be fair if, at the end of the exchange, either each player receives the item it expects or neither player receives any additional information about the other’s item. For instance, in payment protocols, fair exchange can ensure that a customer receives digital goods from a vendor if and only if the vendor receives payment from the customer. The features of the transaction will decide the type of nonrepudiation service to be deployed. For any nonrepudiation service, evidence is a crucial object, and the processing of evidence usually involves the assistance from Trusted Third Parties (TTPs).

There are different activities at each phase of processing. The nonrepudiation policy defines the behavior of these activities. Finally, the eventual success of nonrepudiation depends upon technical and legal supports.

Specific Nonrepudiation Services:

Nonrepudiation services help the transacting parties to settle possible disputes over whether a particular event or action has taken place in a transaction. We define a nonrepudiation protocol as a message flow in which entities exchange digital evidence in order to provide such nonrepudiation services. In an electronic transaction, message transfer is the building block and there are two possible ways of transferring a message

Specific Nonrepudiation Services

—The originator O sends the message to the recipient R directly; or

—The originator O submits the message to a delivery agent D which then delivers the message to the recipient R.

Evidence

Network Intelligence emerges from both web intelligence [42] and broad-based network intelligence such as information and resources distribution, linkages among distributed objects, hidden communities and groups, information and resources from network and in particular the web, information retrieval, searching, and structuralization from distributed and textual data. The information and facilities from the networks surrounding the target business problem either consist of the problem constituents or can contribute to useful information for actionable knowledge discovery. Therefore, they should be catered for in AKD. In saying “network intelligence,” we expect to fulfil the power of network information and facilities for data mining in terms of, but not limited to, the following aspects:

The evidence is the data or information that can be used if a dispute arises. It can be either generated and stored by the local user or by a third party. Its format depends on the cryptographic mechanisms agreed in the service, such as digital signatures (public-key cryptography) and secure envelopes (secret-key cryptography). Whichever the format is, this evidence has to be composed on common information that helps to clearly identify a transaction and thus resolve a possible dispute in a more deterministic way. Some of these common elements are:

—nonrepudiation service to which evidence is related;
—nonrepudiation policy identifier;
—originator identity;
—recipient identity;
—third-party identity if evidence generator differs from the originator;
—message or a digital fingerprint;
—message identifier;
—information needed for verifying evidence (i.e., digital certificate, symmetric secret key information) if it is not publicly available;
—TTP’s identifier and role when involved in the service;
—unique evidence identifier; and
—time information (time and date in which evidence was generated, expiry date, etc.).

If this data is certified by a Time-Stamping Authority (TSA), it could include a time stamp service identifier.When a secure envelope is used to provide evidence, data is stamped with a secret key known only by the TTP, thus being the generator and verifier of evidence as requested by users. The secure envelope maintains integrity of the information using a digital fingerprint (i.e., hash function) and confidentiality (e.g., symmetric cipher with the secret key).

When a digital signature is used to provide evidence, information is enclosed in a data structure digitally signed by a Certification Authority (CA) such that only the CA can sign the data and other participants (recipients and TTP) can verify it. Unforgeable digital signatures provide a clear statement of the essential components of handwritten signatures, namely, a user’s ability to sign by itself, a universally agreed verification procedure, and the assertion that it is unfeasible (or at least very hard) to selectively forge signatures in a manner that passes the verification process without being detected. In order to bring all of this into reality, digital signatures used as evidence in a nonrepudiation service need an infrastructure backing them up. There will be a thirdparty certifying participants’ link between their identity and public key. Only in this way can any recipient can verify the digital signature. Digital signatures introduce a new disrupting element in the nonrepudiation service, as the link certified by the CA (often referred to as digital certificate) may have an expiry date. This fact has to be checked when evidence is verified either by the recipient or a TTP.

If this link has expired, evidence will be valid only if it was generated before. For this reason, time information has to be included in the evidence generated. In general, it is more efficient, in terms of computation, for users to use secure envelopes with symmetric encryption techniques, since the TTP (or smartcard) is in charge of the generation/verification process. Nevertheless, in this case, the following holds.

—Principals have to unconditionally trust a third party for evidence generation and verification;

—TTP’s online availability is needed in order to participate in the service when requested; and

—if users are to relax the TTP participation as stated previously, then they need to use dedicated hardware to avoid the TTP becoming a bottleneck.

You might also like the below seminar topics

Night Vision Technology
Night Vision
Nvidia Tegra 250 Developer Kit Hardware
NVIDIA Tesla Personal Supercomputer
Object-Oriented Concepts
On-line Analytical Processing (OLAP)
OpenRAN
Opera (web browser)
Optic Fibre Cable
Fast Convergence Algorithms for Active Noise Controlin Vehicles
Fast And Secure Protocol

 

<<back


copyright © 2006 V2 Computers E-mail :- contactv2@gmail.com