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

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

Hi Joe,

Next in this developing series and next in line... The network and the enabling of a survivable network system that has 
a total hazard function which lie within the accepted total cumulative bounds when added to the other functions. Thus 
where the risk is minimised. 

 

In the level of the network transport you have to look at communication from the client (covered previously) to the 
system that you are providing services from (at least the gateway of this system).

 

The things to consider (and this is not exclusive) will include:

1                    The level of encryption (if used)

a.      The levels of initial and subsequent encryption that may exist have to both been accounted for. By this you 
need to consider both the key exchange and session key protocols if both are used

2                    The key exchange mechanism and its reliability

3                    The security of the network used. An end-to-end fibre link directly between two hosts is 
impractical in most cases, but may be warranted for certain inter-office communications. 

4                    Private WAN connections using leased lines should be analysed, as these are rarely private any 
longer. Most of the carriers use the Internet to manage these systems and often do it poorly. To take a line from a 
standard leased line contract from one of Australia’s biggest carriers for the provision of a private leased line WAN:

a.      ““XXXX” may use any reasonable means including but not limited to the Internet to manage the router.” The end 
result of which is that unbeknownst to many users of private leased line WAN’s is that the (for example) end-to-end 
frame link they have is actually on the Internet without encryption.

5                    The logging and monitoring of the systems needs to be evaluated. In an idea world, the capture of 
all traffic to/from the device and no other security would actually suffice. This is as any attack that did succeed 
would be recorded and thus any attempt to repudiate could be instantly validated as being based on fact or fraud. This 
would also make the storage companies very happy.

6                    The integrity of the logs is of paramount importance. The level of logging is also crucial in the 
calculation of the survival function, as improved monitoring will increase the survival time.

 

Next and a little later, I will cover the systems and applications at the provider end of the equation.

 

"Yes your system implements non-repudiation on a best-practice basis. Whenever there are problems then you have good 
chances to take legal action". Is not really what you can state. You are better to aim at stating:

“The transactions produced by your system would be difficult to repudiate. When compared to the logs and monitoring on 
your side, the user wishing to repudiate a transaction would have to provide evidence to support his claim to a level 
beyond which is likely to ever be achieved. Your chances of winning a civil suit to enforce payment (or the 
transaction) are high.”

The bit to remember here is that you can protect against the repudiation of a transaction, you can not actually 
implement non-repudiation. I am a bit of a "anal prick" (which I admit fully) when it comes to taxonomies.

 

Regards,

Craig

        -----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.