RE: Proving non-repudiation in e-Commerce App

["Craig Wright" <cwright () bdosyd com au>]

Hi Joe,

For the apps side I will take the easy way out and point you to a number of academic articles.

 

I will start by pointing you to:

Karl Aberer, Anwitaman Datta, Manfred Hauswirth (2003) “Decentralized public key infrastructure for 
customer-to-customer e-commerce” EPFL Technical Report IC/2003/74

 

R. Chen and W. Yeager. Poblano - A Distributed Trust Model for Peer-to-Peer Networks. http://security.jxta.org/.

 

Wichert, M & Caughey D (1999) “Non-repudiation Evidence Generation for CORBA using XML” available at 
http://www.acsac.org/1999/papers/fri-b-0830-wichert.pdf

This is a proposed CORBA based app system analysis.

 

Ning Zhao, David C. Yen, I-Chiu Chang (2004) “Auditing in the e-commerce era” Information Management & Computer 
Security, Dec 2004 Volume: 12 Issue: 5 Page: 389 - 400

 

Otuteye, E (2001) “Framework for E-Business Information Security Management” University of New Brunswick, Canada

 

Yolanta Beres, Adrian Baldwin, Marco Casassa Mont, Simon Shiu (2002) “Identity and accountability in 
business-to-business e-commerce” http://www.hpl.hp.com/techreports/2002/HPL-2002-112.pdf

 

Also the following papers are helpful:

*       S. Kremer and J.-F. Raskin “A Game-Based Verification of Non-Repudiation and Fair Exchange Protocols”, 
*       M. Hiltunen, R. Schlichting and C. Ugarte “Enhancing Survivability of Security Services Using Redundancy”
*       ,  C. Wang, J. Davidson, J. Knight and J. Hill “Protection of Software-Based Survivability Mechanisms”

 

These are a start only. What you are asking is not a simple audit task. Stating that you have the ability to do this 
and auditing the system against such a standard will leave you liable if you cannot do this to the required standard. I 
suggest that you also involve somebody with some experience creating Bayesian distribution models for risk functions.

 

Regards,

Craig

 

See also;

Baum, M & Ford, W. (2001) “Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and 
Encryption”, 2nd Edition, Prentice Hall.

        -----Original Message----- 
        From: Joe [mailto:bitshield () gmail com] 
        Sent: Fri 2/06/2006 2:56 PM 
        To: Craig Wright 
        Cc: security-basics () securityfocus com 
        Subject: Re: Proving non-repudiation in e-Commerce App
        
        
        Hi Craig
        
        thanks for your indepth explanation. You are right, the term prove is too strong. I want to be able to say the 
customer: "Yes your system implements non-repudiation on a best-practice basis. Whenever there are problems then you 
have good chances to take legal action". 
        What does this actually mean? I want to illuminate each component (as you told) the application. For doing that 
I have to know how one implements a proper non-repudiation. For example: 
        
        How does the application log have to look like? I guess the log will be an important part, where you can trace 
and backup the transactions. How does a log entry look like, to prove that it couldn't be altered by the sysadmin or by 
a hacker? 
        
        Every action triggered by the client should somehow be signed using the clients private-key and then stroed in 
a DB or a log file. I think such a solution would implement non-repudiation. What do you guys think? Are there other or 
better practices? I'm looking for applied practices. 
        
        Thanks
        Joe
        
        
        On 6/1/06, Craig Wright <cwright () bdosyd com au> wrote: 


                Hello,
                Firstly there is no way to prove non-repudiation. There is no valid means to prove encryption. For 
those who do not agree, please read up on computational mathematics and the N vs NP problem (also see computational 
theory in general). Micheal Sipser (from MIT) has some excellent papers on the topic. 
                
                Next lets get to prove. Prove is a mathematical determination of a rule. Even in the case of a 
discovered and somehow proven encryption algorithm there is no way to prove non-repudiation.
                
                What does this mean? It comes down to a likelihood determination. This is a probabilistic determination 
of the Cumulative distribution function (CDF) associated with the survival and hazard functions of the plot of time 
against likelihood of compromise. 
                
                Even in cases of a perfect algorithm there is an associated hazard function associated with a brute 
force compromise of the key. In most cases this Probability density Function (PDF) correlates to a Poisson 
distribution. 
                
                So what you are looking at in reality is a survival function that will be acceptable in a court of law 
that will not be readily repudiable by the opposing party.
                
                To do this you need to look at proof beyond reasonable doubt. This is due to the criminal standard of 
proof being used for deceit. As you wish to prove against a person who may be lying this is the necessary level of 
proof. In common law courts this is generally (though not exclusively) held at a determined confidence level (CI) of 
99%. That is an alpha set at 1%. 
                
                Now the determination needs to be complete in a cumulative manner which includes the totality of the 
systems. In this you need to determine the individual hazard function for each of the components. This is than 
extrapolated into the total Survival function estimate for the system. 
                
                One property of the exponential distribution and hence the Poisson process is that it is memory-less 
(This is the number of incidents occurring in any bounded interval of time after time t is independent of the number of 
arrivals occurring before time t). 
                
                Now this means that you are attempting to determine the lambda function λ(t) associated with each 
hazard occurrence (being the likelihood of brute force or other key compromise). The number of expected key compromises 
for each component is than the integral of λ(t) for the period from 0 (start time) to a determined safe time ( i.e. 
promised non-repudiation of 5 years, 25 years etc).
                
                So yes there are ways to achieve what you are asking. What you are looking at is the expected "safe" 
time of your system.
                
                Regards,
                Craig
                
                -----Original Message-----
                From: Joe [mailto:bitshield () gmail com]
                Sent: Friday, 2 June 2006 4:32 AM
                To: security-basics () securityfocus com 
                Subject: Proving non-repudiation in e-Commerce App
                
                Dear List-Members
                
                I'm currently dealing with a review of an e-Commerce Application. One
                goal is to prove that this application properly implements a 
                non-repudiation mechanism throughout the whole process-flow. This flow
                starts at the user authentication, communication over the web to the
                server component, then processing of the client requests and finally
                logging.
                
                The non-repudiation has similarities with e-Banking which points me to
                the following keywords: digital signature, signed logging and time
                stamp protocols. Using Google I also found various sources discussing 
                most of those points individually. However I'm looking for a more
                general, broad and complete approach.
                
                Do you guys have interesting sources and experiences about verifying
                non-repudiation? Are there standards, defined processes, work-flows, 
                and implementation- or audit guidelines?
                


Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
those States and Territories of Australia where such legislation exists.

DISCLAIMER
The information contained in this email and any attachments is confidential. If you are not the intended recipient, you 
must not use or disclose the information. If you have received this email in error, please inform us promptly by reply 
email or by telephoning +61 2 9286 5555. Please delete the email and destroy any printed copy.  

Any views expressed in this message are those of the individual sender. You may not rely on this message as advice 
unless it has been electronically signed by a Partner of BDO or it is subsequently confirmed by letter or fax signed by 
a Partner of BDO.

BDO accepts no liability for any damage caused by this email or its attachments due to viruses, interference, 
interception, corruption or unauthorised access.