Hardware, software and the data that resides in and among computer systems must be protected against security threats that exploit vulnerabilities. Organizations must therefore impose appropriate controls to monitor for, deter and prevent security breaches.
Three areas have been considered, in a typical sense, as the basic critical security requirements for data protection: confidentiality is used to assure privacy; principles of integrity assure systems are changed in accordance with authorized practices; and, availability is applied to maintain proper system functions to sustain service delivery (Dhillon, 2007, p. 19).
These security requirements are represented in Figure 1, Classic Critical Security Requirements. This figure depicts the cross-domain solutions of informal controls, also known as human relationships, and formal and technical controls, which provide for organizational and physical information security controls, respectively.
Two additional security requirements have recently been added that are of particular importance to networked environments because attacks now extend far beyond traditional firewall perimeters. These are authentication, which is used to assure a message actually comes from the source it claims to have originated; and, nonrepudiation, which can be applied to prevent an entity from denying performance of a particular action related to handling data, thereby assuring validity of content and origin.
Figure 2, Core Data Security Set, depicts the interrelationship of the five core requirements of information security. The remainder of this paper will focus on nonrepudiation, which may also be explained as a security protocol that allows an individual or organization to prove, for instance, that someone sent an email or made a web-based purchase. In other words, “one party of a transaction cannot deny having received a transaction, nor can the other party deny having sent a transaction” (Professional Development Center, 2010).
Types of Nonrepudiation Controls
Asymmetric ciphers make public keys widely available for encrypting information, but only one individual possesses a private key to decrypt or decipher that information, and vice versa. Asymmetric cryptography, invented by Diffie and Hellman in 1975, can be used to authenticate a source such as a digital signature. RSA, named for Rivest, Shamir, and Adleman who first described this process and make it public, is an example of an asymmetric cipher algorithm. RSA uses a public key, available to everyone for encrypting messages. RSA then applies a limited-availability private key for decryption by the end user as represented in Figure 3 below.
Secure Socket Layer (SSL) encryption technologies also offer controls for non-repudiation to provide communications and data security over the internet. SSL uses asymmetric cryptography for privacy as well as keyed message authentication for message reliability. A Trusted Third Party (TTP) is often used for authentication in order to successfully implement non-repudiation controls. Just as a notary public will validate a signature, SSL certificates validate a user's transactions on the internet. Figure 4 below depicts two users making a data transaction across the internet.
This representation demonstrates data sent from User #1 and User #2 through the internet on a web browser such as Google Chrome or Safari. The web browser automatically encrypts the submitted data utilizing SSL encryption protocols. These encryptions must be trusted and verified, similar to how a notary public must witness the signature of a client before initiating their own seal of approval. This trust comes from the Trusted Third Party service providers. As the encrypted data transverses the internet, it will travel through the TTP, where they will authenticate with their own seal of approval. After the certificate checks out, the encrypted and certified data reaches its destination.
The non-repudiation controls that SSL certificates offer reside in the protocol itself. As a user encrypts the data he/she sends out, the SSL protocol will place a "personal key" on the data. This key is unique to every user. This personal key would be equivalent to someone's signature. In order to verify the signature and the SSL encryption, the TTP will verify the authenticity of the certificate. This validation is what makes the SSL certificate solidify that the sender, as opposed to anyone else, sent the information. Absent a "personal key" encrypted in the message and no validation from a TTP, then the message could not be traced back to a single user. In other words, information sent from user #1 could not be traced back and verified.
Potential Losses
Vulnerabilities must be understood to protect against threats to and attacks in information systems. Similarly, identifying and assessing potential losses is important. Hardware, software and the data that resides in computer systems must be secured, thereby assuring the integrity of these key components have not been modified in any way. This practice will help prevent vulnerabilities from being exploited (Dhillon, 2007, p. 17).
Losses for an Information System could be devastating if nonrepudiation processes were to be compromised or defeated. The customer base, for example, will lose faith in the viability of the system if it is disrupted and authenticity cannot be verified. Identity theft could occur where private and personal data could be lost or stolen. Since no security technology is absolutely full-proof, a digital signature alone may not always guarantee nonrepudiation.
Effective security is the result of the implementation of several tools, each focusing on a particular security requirement. Multiple tools should be used to prevent additional losses. Some examples include applying unique biometric information as a method of validation and verification, as does securing additional information about the sender or signer which, in combination, would further harden the system.
These would make repudiation increasingly difficult in situations involving the use of digital signatures when combined with added protective features. A loss of nonrepudiation would result in the questioning of the transactions that have occurred. Nonrepudiation protocols can be applied to e-mail accounts to minimize potential losses. Application security, for example, can be provided by router filters and server operating systems.
Nonrepudiation, in this instance, will help assure mail senders and recipients are not using phishing and e-mail scams to gain access to personal information as it travels. Instituting the use of hardened passwords, as well as enforcing rigorous policies on frequent changes and restricting reuse, are measures that may be implemented to deter attacks and prevent losses.
Figure 5 below depicts the importance and interdependency of nonrepudiation, among the other critical security requirements, to electronic commerce.
Electronic commerce uses technology such as digital signatures and encryption to establish authenticity and non-repudiation. Any Information Technology security system must validate that confidentiality, integrity and availability of data is always protected with redundant layers of encryption and non-modification controls. Specific nonrepudiation measures that protect the hardware, software and system data, along with authentication methods, while relatively new in comparison to the three basic security control requirements, cannot be overlooked when designing, constructing and placing a system into production. Examples include research data, medical and insurance records, new product specifications, and corporate investment strategies. In some locations, there may be a legal obligation to protect the privacy of individuals. This is particularly true for banks and loan companies (DHS, 2008).
Example Applications – Practical Implementation of Nonrepudiation
Nonrepudiation, from a legal perspective, implies a person, party or organization’s intention to fulfill its contractual obligation so that none of the parties involved should be capable of denying receiving or sending a transaction. Electronic commerce uses technology such as digital signatures and public key encryption, as discussed earlier, to establish non-repudiation & authenticity. Electronic commerce generally relates to trading of products or services over Internet or computer network. However, it is not exclusive to buying and selling products since it includes following online processes and properties.
The following four (4) properties must be satisfied to successfully implement non repudiation in any transaction:
1. Transactions and customers must be tightly bound;
2. Transactions must be difficult to forge;
3. Transactions must be unalterable; and;
4. Transactions must be verifiable.
Nonrepudiation architectures that incorporate these essential properties are the Challenge Response OTP Token and the Digital Signature. The general internet architecture needs to be understood in order to better elaborate on these examples. Figure 6 represents a customer connection to a web server that implements security layers for authentication.
In this representation, the customer uses a web browser and connects to a web server of any organization using Secure Socket Layer (SSL) / Transport Layer Security (TLS) for authentication and to conduct a transaction. The web server communicates with the authentication server for user authentication and with a backend for accomplishing the transaction request.
Implementing a Challenge Response OTP Token, depicted in Figure 7, requires the customer to submit positive identification to authenticate and sign legal documentation that is used to establish an account with an organization. The customer then receives the OTP token, which is assigned a unique serial number ensure a strong binding with customer-user. When the customer initiates a transaction using an OTP token, it creates an SSL session between web server and browser, after which the customer logs in by sending a login identification and password to web server through the SSL. The server returns a challenge, this challenge is entered into token by customer to generate response, the customer sends this response through the browser to achieve server for validation, and once this process is successfully completed, the client and server are connected.
The customer, after presenting verifiable identification and gaining access, receives a code and instructions to apply a unique public/private which must be submitted to gain a digital certificate. The customer and private key are bound together through the digital certificate as shown in Figure 8.
This scenario shows that when a customer or client initiates a connection to organization, an SSL session is opened between the browser and web server, and the client is authorized to complete transactions once his or her identification and password are successfully entered and authenticated. The back end receives the transaction request, validates the signature information, and once successfully validated, the transaction may continue.
In closing, it must be understood there are certain variables that must be considered when applying a Challenge Response OTP Token and Digital Signature as nonrepudiation methods. These include costs, technical support, speed, latency time and others. A comparison of these important variables is provided in Figure 9.

Works Cited

Dhillon, G. (2007). Principles of Information Security Systems. John Wiley & Sons, Inc.

DHS. (2008). US CERT. Retrieved September 14, 2011, from United States Certification: http://www.us-cert.gov/control_systems/pdf/SCADA_Procurement_DHS_Final_to_Issue_08-19-08.pdf

Professional Development Center. (2010). Retrieved September 7 from http://pdc-riphah.edu.pk/site/?page_id=69