Non repudiation
1 / 45

- PowerPoint PPT Presentation

  • Updated On :

Non-repudiation. Robin Burke ECT 582. Midterm scores. Ave: 69 Std. dev: 23 Median: 75 Max: 100 Min: 35. Approximate grade. Mid 80s and up: As High 60s and to mid80s: Bs 50s to 60s: Cs 40s: Ds. Midterm. Answers. Law and Business. Legal systems make business possible

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - naava

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Non repudiation l.jpg


Robin Burke

ECT 582

Midterm scores l.jpg
Midterm scores

  • Ave: 69

  • Std. dev: 23

  • Median: 75

  • Max: 100

  • Min: 35

Approximate grade l.jpg
Approximate grade

  • Mid 80s and up: As

  • High 60s and to mid80s: Bs

  • 50s to 60s: Cs

  • 40s: Ds

Midterm l.jpg

  • Answers

Law and business l.jpg
Law and Business

  • Legal systems make business possible

    • (sorry libertarians)

  • Law establishes

    • conditions for contract validity

    • venues for disinterested mediation and dispute resolution

    • remedies for breach of contract

    • mechanisms of enforcement

Law and e commerce l.jpg
Law and E-Commerce

  • E-Commerce also needs legal systems

  • Complexities

    • global scope / jurisdiction

    • evolving technology landscape

    • automation / liability

Evidence l.jpg

  • Legal systems require evidence

    • evidentiary statutes predate digital era

    • slowly catching up

  • Non-repudiation

    • maintaining digital evidence for e-commerce transactions

Legal structures l.jpg
Legal structures

  • Common law

    • long-established precedents in US and UK

  • Concepts

    • writing

    • signing

    • notary

    • competence

    • presence

    • negotiability

Problems for e commerce l.jpg
Problems for e-commerce

  • Is a digital contract "written"?

    • digital media impermanent

  • Is a digital signature a "signature"?

    • must be qualified with respect to key purpose, policy, etc.

  • Who bears liability?

    • private key compromise

    • service disruption

  • Who will archive and how?

    • digital media volatile

    • archives must be secure

Example l.jpg

  • Financial services law

    • banks must retain canceled checks

      • or facsimiles thereof (microfilm)

    • pre-dates digital era

  • If we define "digital representation"

    • as equivalent to physical facsimile

    • then banks can store electronic scans of canceled checks

Example11 l.jpg

  • Jurisdiction

    • location where suit can be brought

    • party must have "minimum contacts" with a jurisdiction to be summoned there

      • US Constitutional law

  • Does the availability of web site constitute "minimum contacts"?

Legal framework us federal l.jpg
Legal frameworkUS Federal

  • Federal law

    • Federal E-Sign act

    • provisions

      • Technology-neutral

      • Electronic signatures have same status as written ones

      • limits

        • applies mostly to sale and lease contracts, will, trusts and other transactions explicitly excluded)

Legal framework us state law l.jpg
Legal FrameworkUS State Law

  • Uniform Electronic Transactions Act

    • More specific than Federal law

    • Enacted by 43 states

    • Still technology-neutral

      • Doesn't mention certificates, PKI, etc.

  • Uniform Computer Information Transactions Act

    • Extremely controversial

    • Enacted by 3 states: Maryland, Virginia, Iowa

    • Major concern

      • imposition of onerous license terms: self-help, reverse engineering, prevention of archiving, fair-use, etc.

Ueta provisions l.jpg
UETA Provisions

  • Electronic Signature

    • "an electronic sound, symbol. or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record."

  • Effect of Electronic Signature: A

    • "signature may not be denied legal effect or enforceability solely because it is in electronic form.""If a law requires a signature, an electronic signature satisfies the law."

  • Electronic Record

    • "Means a record created, generated, sent, communicated, received, or stored by electronic means."

  • Effect of Electronic Record

    • A record "may not be denied legal effect or enforceability solely because it is in electronic form."

    • If a law requires a record to be in writing, an electronic record satisfies the law."

    • A contract may not be denied legal effect or enforceability solely because an electronic record was used in its formation."

  • Effect of Electronic Agents

    • "The actions of machines ("electronic agents") programmed and used by people will bind the user of the machine, regardless of whether human review of a particular transaction has occurred."

Digital signature law l.jpg
Digital Signature Law

  • Utah Digital Signature Act (1995)

    • Very specific

      • Mentions public key cryptography, certificates, CRLs, etc.

      • Licensing and regulation of CAs

      • Liabilities of users and CAs

    • Not widely emulated

  • "Digital Signature Guidelines" (1999)

    • American Bar Association

    • Guidelines for the deployment of PKI

      • Expectations and liability associated with CAs, RAs, and users

International laws l.jpg
International Laws

  • UN Model Law on Electronic Commerce

    • similar to UETA

  • EU Directive on Digital Signatures

    • similar to Utah law

    • specific requirements for PKI

State of law l.jpg
State of law

  • Complex and unsettled

    • Different laws in different states / countries

  • Catch-22

    • Slow adoption of PKI is tied to legal uncertainties

    • Lack of legal precedents / guidelines due to slow adoption

Non repudiation19 l.jpg

  • System property

  • Protocol

    • provides for the retention of evidence

    • that can be used to resolve disputes

    • regarding transactions

Non repudiation20 l.jpg

  • Strong and substantial evidence of the identity of the signer of a message and of message integrity, sufficient to prevent a party from successfully denying the origin, submission or delivery of the message and the integrityof its contents.

  • ABA Digital Signature Guidelines

Disputes l.jpg

  • "I never said that."

    • origin

  • "I never got your message."

    • reception

  • "Check's in the mail."

    • submission

Types needed l.jpg
Types needed

  • Non-repudiation of origin

    • NRO

  • Non-repudiation of delivery

    • NRD

  • Non-repudiation of submission

    • NRS

Non repudiation of origin l.jpg
Non-repudiation of Origin

  • Evidence needed

    • Identity of originator

    • Contents of message

    • Time of generation

      • this may matter for establishing a negotiation sequence

  • Techniques

    • two party

    • three party

Originator digital signature l.jpg
Originator Digital Signature

  • Alice

    • creates message M

    • dates it T

    • and signs it S

  • Alice sends M + T + S to Bob

  • Bob uses Alice's public key certificate to verify signature

  • Bob archives

    • M + T + S

    • Alice's public key certificate and CRL used to verify it

Features l.jpg

  • Identity and contents are protected

  • Timestamping depends on the accuracy of Alice's clock

  • Alice needs digital signature capability

Ttp signature l.jpg
TTP Signature

  • Trusted third-party (Vicky)

  • Receives Alice's transaction M

    • message

  • Generates time stamp T

  • Signs M + T

    • creating S'

  • Returns to Alice

  • Bob gets M + T + S'

    • can verify that whole transaction matches S'

    • archives the message for dispute resolution

    • also Vicky's certificate and CRL used to verify it

Features27 l.jpg

  • Alice doesn't need to sign

    • she can review message before sending

    • Alice doesn't need a key pair

      • lower PKI overhead

  • Timestamp

    • Vicky's timestamp will be more reliable than Alice's

  • Identity less secure

    • no digital signature from Alice

  • Vicky has access to message contents

Ttp digest signature l.jpg
TTP Digest Signature

  • Alice doesn't want to disclose M

  • Same operation with hash of M using key k

    • creates hash H

  • Sends H to Vicky

    • gets back H + T + S'

  • Attaches M

    • encrypts M + k + H + T + S'

  • Bob receives message

    • verifies that H is a true hash of M

    • verifies Vicky's signature

    • archives the transaction

Features29 l.jpg

  • Alice needs encryption / hashing capability

  • Confidentiality is preserved

  • Identity still a problem

In line ttp l.jpg
In-line TTP

  • Receives Alice's transaction M

    • message

  • Generates time stamp T

    • Signs M + T

    • creating S'

  • Archives M + T + S'

  • Forwards M to Bob

    • perhaps with transaction id

  • Bob can contact Vicky to get evidence

Features31 l.jpg

  • Vicky does archiving

  • Alice and Bob don't need encryption capability

  • Content and identity guarantees

Ttp token l.jpg
TTP Token

  • Receives Alice's transaction M

  • Generates time stamp T

  • Creates a secure hash H of M + T using a cryptographic key k

  • Returns to Alice M + T + H

  • Bob gets M + T + H

    • Bob can contact Vicky with H

    • Vicky verifies that H matches message

Features33 l.jpg

  • Content secure

  • No PKI

    • Ordinary symmetric encryption sufficient

  • Identity less secure

Combination of methods l.jpg
Combination of methods

  • Originator Signature + TTP Digest Signature

    • if we care about disclosure

    • and recipient can archive

  • Originator Signature + In-line TTP

    • if we don't care about disclosure

    • and we want 3rd party archiving

  • In-line TTP could

    • archive encrypted message

    • Bob would need private key to access evidence

Non repudiation of delivery l.jpg
Non-repudiation of delivery

  • Same information needed

    • Identity of recipient

    • Content of message

    • Timestamp

  • Think of NRO

    • but the origin message is the acknowledgement of receipt

Signed receipt l.jpg
Signed receipt

  • Alice sends Bob M

  • Bob

    • generates a timestamp T

    • computes a hash of M = H

    • signs H + T = S'

    • sends Alice a receipt message H + T + S'

  • Alice

    • checks H against her original message

    • validates Bob's signature

    • archives the receipt message

Features37 l.jpg

  • Like digital signature NRO, but in reverse

    • message = acknowledgement

  • Standardized part of S/MIME

    • secure receipt of email

    • available in MS Outlook

  • Other variants

    • TTP Signature, In-Line etc.

      • all the same options available

Problem l.jpg

  • Requires that the recipient generate the receipt

  • What about the "reluctant recipient"?

    • reason for NRD in the first place

Trusted delivery agent l.jpg
Trusted Delivery Agent

  • Alice sends message of Vicky

  • Bob must contact Vicky to access message

    • Vicky generates receipt

Non repudiation of submission l.jpg
Non-repudiation of submission

  • Useful when what matters is submitting something

    • a bid

    • acceptance

  • Like NDD

    • but with the mail system

      • or the bidding engine

    • doing the verification

Basic idea l.jpg
Basic idea

  • Parties agree to non-repudiation mechanism

  • Evidence is generated during transaction

  • Evidence is transmitted

  • Evidence is verified

  • Evidence is archived

  • If necessary

    • Evidence is retrieved

    • Evidence is presented for dispute resolution

Digital evidence l.jpg
Digital evidence

  • Evidence will be strong if

    • secure chain of custody from creation to presentation

    • properties of authenticity and integrity

    • policies of the CA and TTP

Secure bidding l.jpg
Secure bidding

  • Suppose Alice doesn't want Bob to know the contents of her message

    • a bid to be unsealed later

  • Additional safeguards

    • Alice shouldn't be able to change her mind

    • Bob shouldn't be able to read her bid

  • "Commitment protocol"

    • Alice commits to an answer but doesn't reveal it

Commitment protocol l.jpg
Commitment protocol

  • Alice encrypts M with symmetric key k

    • produces ciphertext C

    • generates the transaction based on C

  • Bob gets Alice's bid C

    • he can verify identity and timestamp

    • gets copy of C

  • When bids are revealed

    • Alice transmits k

    • Bid can be read

Homework 4 l.jpg
Homework #4

  • Use secure email

    • digital signature

    • encryption

  • Get certificate from

    • cannot use web mail

    • if necessary, open a new hotmail account

    • Use Outlook Express or Netscape Communicator