Question

Try to make it as simple as you can and explain as much as it needed.

1. What is Trusted Third Party (TTP)? What are the problems with TTP? (3 points)

Ans:

2. Using Caesar cipher algorithm and key value = 4, encrypt the plain text “Network Security”. Show your work.          (3 points)

Ans:

1. Let k be the encipherment key for a Caesar cipher. The decipherment key differs; it is 26 - k. One of the characteristics of a public key system is that the encipherment and decipherment keys are different. Why then is the Caesar cipher a classical cryptosystem, not a public key cryptosystem? Be specific.                                                 (3 points)

Ans:

2. A cryptographer once claimed that security mechanisms other than cryptography were unnecessary because cryptography could provide any desired level of confidentiality and integrity. Ignoring availability, either justify or refute the cryptographer’s claim. (3 points)

Ans:

3. How can you ensure Authentication using Challenge and Response method? Explain and give an example. (4 points)

Ans:

Answer 1

1)

A trusted third party (TTP) can be described as an entity trusted by other entities with respect to security-related services and activities. A TTP would be used to offer value added services to users wishing to enhance the trust and business confidence in the services they receive and to facilitate secure communications between business trading partners. TTPs need to offer value with regard to integrity, confidentiality and assurance of the services and information involved in the communications between business applications. In addition, users will require TTP services to be available when they need them within the terms of the agreed service contract. Typically, a TTP will be an organization, licensed or accredited by a regulatory authority, which will provide security services, on a commercial basis, to a wide range of bodies, including those within the telecommunications, finance and retail sectors. The initiatives such as the European Information Infrastructure (EII) and the Global Information Infrastructure (GII), which aim to facilitate the development of electronic commerce, are good examples where there is a need for security services and TTPs. This is an important part of the motivation to use TTPs to support secure communications in commercial systems and a variety of industry sectors. For example, a TTP could be used to support the provision of digital signatures to secure the integrity of documents. In addition, they could provide end-to-end encryption services to users, and incorporate e.g. key escrow/recovery functionality to support a recovery or backup function for a key to enable recovery if the key is lost (typically for documents and files that have been encrypted by employees) or to support the demand for lawful interception. The use of TTPs is dependent on the fundamental requirement that the TTP is trusted by the entities it serves to perform certain functions. However, the TTP can also assure the user of the trustworthiness of another of its clients to the extent that it is who it claims to be and providing that the other TTP client also trusts the TTP to perform the required functions. This has the advantage that trust between any two entities in a TTP domain can be established without having to set up individual bilateral agreements. In practice, TTPs could exist in both public and corporate domains, at the local, national and international level. TTPs should have trust agreements arranged with other TTPs to form a network, thus allowing a user to communicate securely with every user of every TTP with whom his TTP has an agreement. However, users might not have to communicate with other TTPs other than their own to enable such secure communications to take place. Any TTP scheme should also allow for both national and international operation, allowing users in any country, where an appropriate TTP resides, to communicate securely. Online communications between TTPs should not be required. However, in some circumstances response times may necessitate on-line communications between TTPs. A TTP scheme should ensure that any attempted abuse by a user can be detected, and in addition those with lawful authorization to have access to information cannot fabricate false evidence. A TTP service can be composed of a number of services, each provided by independent organizations on a commercial basis. For example, a notary service provider can sub-contract the CA and directory services to other organizations. A TTP architecture might have a modular design and interfaces to allow for flexible configuration of the system according to the needs of different roles and organizations. Any TTP standards should not restrict the form of electronic communication that can be supported

An example

Suppose Alice and Bob wish to communicate securely – they may choose to use cryptography. Without ever having met Bob, Alice may need to obtain a key to use to encrypt messages to him. In this case, a TTP is a third party who may have previously seen Bob (in person), or is otherwise willing to vouch for that this key (typically in an identity certificate) belongs to the person indicated in that certificate, in this case, Bob. In discussions, this third person is often called Trent. Trent gives it to Alice, who then uses it to send secure messages to Bob. Alice can trust this key to be Bob's if she trusts Trent. In such discussions, it is simply assumed that she has valid reasons to do so (of course there is the issue of Alice and Bob being able to properly identify Trent as Trent and not someone impersonating Trent).

Problems with TTP

1) New Trusted Third Parties are Costly and Risky

2) Existing Trusted Third Parties are Valuable

3) New Trusted Third Parties Can Be Tempting

2) In cryptography, a Caesar cipher, also known as Caesar's cipher, the shift cipher, Caesar's code or Caesar shift, is one of the simplest and most widely known encryption techniques. It is a type of substitution cipher in which each letter in the plaintext is replaced by a letter some fixed number of positions down the alphabet. For example, with a left shift of 3, D would be replaced by A, E would become B, and so on. The method is named after Julius Caesar, who used it in his private correspondence.

3) The Caesar cipher a classical cryptosystem, not a public key cryptosystem because one can derive the decryption key from the encryption key "easily". Caesar cipher is a classical cryptosystem because in our case sender and recipient share a common key while in public key cryptosystem they do not. In public key cryptosystem it must be computationally infeasible to derive the private key from the public key ( second condition of public key) cryptography which is not the case with the Caesar cipher.

4) It is possible to have some sort of integrity and confidentiality if you encrypt or put tamper resistant configurations to a document. But when we talk about information security used in for example an enterprise where human works (which is bad security in itself), I would conclude that integrity and confidentiality need each other to work as intended.

5)

In information security, challenge-response authentication is a type of authentication protocol where one entity presents a challenge or question, and another entity provides a valid response to be authenticated. Challenge-response authentication is a type of authentication method used to prove the identity of a user or other entity requesting access to a computer, network or other network resource. This method uses previously answered challenge questions to authenticate the user; simple user ID and password authentication is the most commonly implemented type of challenge-response system.There are different approaches to authentication using challenge-response systems, but modern challenge-response authentication methods typically incorporate one or more cryptographic protocols to prove the user being authenticated knows a password without the need to share the password itself.In challenge-response authentication, the client application initially obtains a random challenge -- usually data of some type -- from the server. For password-based challenge-response systems, the client system computes a response by applying a cryptographic hash function to the challenge from the server combined with the user's password. Then, the application sends the response, as well as the original challenge, back to the server.When the server receives the response, it applies the same hashing function to the challenge data combined with its own copy of the user's password. If the resulting value and the response sent by the application match, there is a very high degree of probability the user has submitted the correct password.While challenge-response authentication systems generally rely on cryptography to securely authenticate users, CAPTCHA (the Completely Automated Public Turing Test to Tell Computers and Humans Apart) challenge-response system is an example of a noncryptographic challenge-response protocol designed to differentiate humans from robotic software programs. CAPTCHA is used to prevent spam and auto-registration of new accounts for email or websites.

How challenge-response authentication works

When a user attempts to log onto a system or network resource, the challenge-response system server generates a challenge, usually a random number, that is then sent to the client machine.

The client software uses a secret key, or a key based on its password, to encrypt the challenge data using an encryption algorithm or one-way hash function. It then sends the result back to the network server.

The challenge-response authentication system performs the same cryptographic process on the challenge, comparing its result to the response from the client. If the two values match, the authentication system is able to authenticate the client.

There are two types of challenge questions: static and dynamic.

Static questions enable the user to choose from a bank of predefined questions or allow the user to create custom challenge questions. The user then provides the answers to the challenge questions he has selected. For example, a static challenge might be to provide the name of the user's first pet, first car or first-grade teacher -- the correct values will not change over time, and the user can specify the correct values as part of their account setup.

Dynamic questions are created by extracting public data about the user that the individual should know, such as a previous street address or the make and model of a previous vehicle. The system presents the user with random questions and answers that utilize this data from which the user must select the correct answer.

Challenge-response authentication can defend against session replay attacks, in which an attacker listens to previous messages and resends them later to get the same credentials as the original message. Challenge-response systems defend against replay attacks, because each challenge and response is unique. An attacker monitoring credentials exchanges and then attempting to reuse credentials will not succeed in gaining access.

Some types of challenge-response systems can help defend against man-in-the-middle attacks, particularly when the challenge and response requires some knowledge to which the attacker does not have access. For example, challenge and response values that are digitally signed by an endpoint using a private key, or that depend on any other data that has not been compromised by an attacker, should protect the endpoint from a man-in-the-middle attack.

Some examples of challenge-response authentication systems include the following:

• The secure shell protocol includes a challenge-response mechanism that uses a separate public key pair for each direction of a communication session. A local client authenticates itself to a remote server by sending the server a value signed with the server's public key. The remote server authenticates itself to the client with a value signed with the client's public key.
• Zero-knowledge password proof systems depend on cryptographic methods that enable both parties -- client and server -- to authenticate to each other. These systems allow each party to confirm to each other that they have a correct password, but without the need to share that password with each other.
• Challenge-Handshake Authentication Protocol (CHAP), specified in IETF RFC 1994, defines an authentication protocol that uses a three-way handshake. The authenticating system sends a challenge message to the system being authenticated. The next step is for that system to perform a one-way hash on the challenge and return the hash value to the authenticating system. The authenticating system can then allow the session to continue if the hashed values match, or terminate the connection if they don't.
• The OATH Challenge-Response Algorithm (OCRA) is another challenge-response authentication method, defined in IETF RFC 6287. It uses a challenge-response algorithm developed by the Initiative for Open Authentication (OATH) for a cryptographically strong challenge-response authentication.