Security Basics mailing list archives

RE: Proving non-repudiation in e-Commerce App - Clients


From: "Craig Wright" <cwright () bdosyd com au>
Date: Sat, 3 Jun 2006 07:22:16 +1000


Hi Joe,

First a comment based on responses not on the list. Non-repudiation is not protocol verification. It is a function of 
obtaining legally admissible scientific proof.  The marketing hype from certificate authorities is just that. Hype. So 
in answer to the idea that you may categorically exclude all possibility of any transaction being repudiated, not 
possible.

 

Now however it is possible to minimise the likelihood of an occurrence.

 

To do this needs to be thoroughly comprehensive.

 

Starting from the client:

1                    They need to be legally bound (notice this is before any technical solution)

2                    They must be authenticated and authorised using a method that proves it was the person who signed 
up. Banks, Post offices, customs etc have processes to “enrol” people. 

3                    The client host must be secure. There are two simple ways to do this:

a.      A legal contract where the end user assumes all responsibility and liability for any actions that have resulted 
from his/her host.

b.      Actually try and secure the thing, firewall IDS controlled access, monitored logs et al to a standard that 
would make most investment banks and casino’s blush.

4                    The authentication method needs to be “provably” secure (to the required standard) – generally as 
in the last post this would be a totality of alpha =1% or a criminal standard of proof.

5                    The better the authentication method the higher the survival model and thus the more likely that 
you can assert that the process cannot be repudiated.

6                    Multiple levels of authentication increase this. Having a biometric signature with a smart card 
that holds a high level private key from a repudiable source.

7                    The high the level of protection against repudiation the higher the costs.

8                    All of this together gives a cumulative likelihood of success. Each like increases the probability 
of a failure. 

 

The network and your systems will follow in subsequent posts… Network next 

 

Regards,

Craig
 
PS the quantitative data for the survival risk model is available but it is computationally difficult. You need to have 
somebody with actuarial and info sec skills. They are available, but they cost. 

 

SAS and SPSS have base inference engines that you can develop for a schotastic  analysis of the data using Monte Carlo 
sim’s for example. R will do this without having to pay as much. R is more difficult to use for the novice though.
 
PPS Pen testing has ABSOLUTELY nothing to do with non-repudiation!
 

        -----Original Message----- 
        From: bitshield () gmail com [mailto:bitshield () gmail com] 
        Sent: Fri 2/06/2006 9:19 PM 
        To: security-basics () securityfocus com 
        Cc: 
        Subject: Re: 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
        


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.

Current thread: