Lecture 18 Scribe Notes

By Marshall Ha, Aaron Chen, Carlos Albuja, Sayyed Alireza Binesh

Protect a computer against adversaries. A computer system performs actions on behalf of principals.

Principals: A model of a user with some rights and privileges. Examples:

• Can a principal log in?
• Can a principal read a file?
• Can a principal write a file?
• Can a principal call fork() and other system calls?
• Can a principal reboot the machine?

The root/administrator often has all the rights and privileges that a computer system can grant.

Is every action performed by a correct principal?
The following two criteria determine whether a computer system should perform an action.

Is the request real?

• Authenticity: Request is authentic if it was made by a real principal.
  • Ex: "Are you really the President of the USA?"
• Integrity: Request is high integrity if it equals the request made by the principal.
  • Ex: Rosencrantz and Guildenstern Are Dead...upon their own request. The death order they commissioned--originally for Hamlet--is altered by Hamlet to place them in harm's way...Low Integrity

Is the request allowed?

• Policy: Request satisfies the policy if the principal has the rights and privileges required for the request.
• Correctness: Request implementation is correct if the code that executes the request performs only the authorized action.
  • Ex: a buffer overrun bug. This would look like an acceptable request like opening a file, but resulting in a reboot of the system. This definitely violates Correctness.

Positive goal (+): System should perform all authentic, authorized actions.
Negative goal (-): System should not perform any inauthentic or nonauthorized actions.

These two goals cannot both be realistically met.1) Rather, our priority is robustness within the system. It is nice to allow every good action, but doing so tends to open the door for bad actions. It is much more DIFFICULT to ensure reasonable prevention of all bad actions.

For some systems, performance is robustness. Consider the Domain Name System (DNS). This system of root servers is the "base" of the internet. It is what maps domain names to usable ip addresses, so poor performance here carries a grave cost. This system ensures robustness through:

1. Storing only public information: This simplifies policy: All reads are OK, and writes are handled specially. The number of reads should overwhelm the number of writes.
2. Only one principal for read requests: "Anyone." This simplifies authentication.
3. Caching and replication: This allows many servers to respond to requests, and avoids attacks which are designed to flood the servers with requests.
   • does not conflict with policy because of public nature of data

These three things imply that the root servers do essentially ONE thing and do it well. First, we see that mere reads of public data will always meet the negative goal. Second, because of specialization, and efficiency of caching/replication, performance is so great that the DNS can handle DOS attacks. Both cases ensure robustness by always preserving a functioning DNS. ...except in the case of nuclear attacks...

Passwords: An authenticity technique.

First login process:
A -> B: Hi, I'm Alice.
B -> A: What's your password?
A -> B: pass

If the path between A and B is trusted, then no information escapes. Of course, this can only be assumed when your server/computer is not connected to other systems, which isn't very interesting.

Threat Model: A threat model is defined in two parts:

1. What consequences should our protocol prevent?
2. What actions may attackers perform?

Let's introduce a threat model: Eve (E) can eavesdrop on links. Then, E can snoop Alice's name and password. This causes an authenticity problem. For sure, we must protect Alice's password, but in some cases we are not as concerned with Alice's name. That issue would be resolved by considering the particulars of the server's function.

Keep a message's contents secret, even from attackers. Trapdoor Function: This is a function which, given f and x, is easy to compute f(x). However, when given f and f(x), it is hard (in the sense of NP-hard) to compute x. Implementations utilize:

• Prime numbers: easy to find, but, when combined, difficult to factor.
• Modular Exponentiation:

Let E be a function, M be a message, K be an encryption key, and K^-1 be the decryption key.

• Given E, K, M, it is easy to find E(K,M).
• Given E, E(K,M), it is hard to compute M, K^-1.
• Given E, E(K,M), K^-1, it is easy to compute M.

Example:
E(K,M) = XMPPR.
This is difficult to decode into M, but when given K:

Then the message can be decoded to be:
M = HELLO

Eavesdropping, but not message alteration.
  Do not expose password.

Only with encrypting the password, there would be still some other ways to attack the system as follows:

Attempting to break a cryptographic protocol by sending a message again that was part of an earlier exchange.

Example:
A -> B: Hi, I'm Alice.
B -> A: What's your password?
A -> B: E(KAB, PassA)

Here is how the attack would happen:
E -> B: Hi, I'm Alice.
B -> E: What's your password?
E -> B: E(KAB, PassA) (Eve can login by just replaying Alice's Password)

Eve can now proceed as Alice. To limit Eve's capabilities we can encrypt commands. With that, Eve cannot do just any command, but must wait for Alice to make some command and attempt to replay it in a later session:

E -> B: Hi, I'm Alice.
B -> E: What's your password?
E -> B: E(KAB, {PassA})
E -> B: E(KAB, {Plant a tree!})
E -> B: E(KAB, {Plant a tree!})
.
.
.

This could still compromise Alice's account. A possible solution to make the system even more secure against thieves like Eve and to eliminate such a replay attack would be to add a NONCE.

NONCE: A random number included in a cryptographic protocol to thwart replay attacks.

Example:
A -> B: Hi, I'm Alice.
B -> A: What's your password, NONCE?
A -> B: E(KAB, {PassA, NONCE})

When Eve goes to replay the E(KAB, {PassA, NONCE}) obtained from Alice's communication, she will find that the NONCE has changed, and the encoded password is no longer valid. Eve is now defeated.

Now let’s think about a scenario where someone (like Lucifer) has full control over channel. This means he can watch all the information between Alice and Bob (like Eve), but can do better by intercepting messages and replacing them with his own. Lucifer can wait for Alice's validation, then proceed, thus sidestepping NONCES. So, the system can be attacked again:

A -> B: Hi, I'm Alice.
B -> A: What's your password, NONCE?
A -> B: E(KAB, {PassA, NONCE})
A -> B: Plant a tree!
L -> B: Burn all Forests!

Since Lucifer knows all about the information between Alice and Bob, then Lucifer can easily send a wrong command to Bob just like “Burn all forests”. In order to prevent this particular attack, we can, as above, encrypt the commands as well as follows:

A -> B: E(KAB, {Plant a tree!})

However, the same mitigated REPLAY attack that Eve could impart without NONCES is a viable attack for Lucifer.

A -> B: Hi, I'm Alice.
B -> A: What's your password, NONCE?
A -> B: E(KAB, {PassA, NONCE})
A -> B: E(KAB, {Plant a tree!})
L -> B: E(KAB, {Plant a tree!})
.
.
.

To fix such a problem, we need to change or increment NONCE every time, so it can be different to Bob.

The Wikipedia article on authentication: includes links to a number of commonly used secure authentication methods.

An important advantage to Public-Key encryption is that it is quite simple to coordinate keys between valid users and servers. Secret-Key encryption had the little problem of actually synchronizing the keys to be used. One could imagine a brief meeting in some café where an envelope is passed where user and server could be sure that the keys are indeed the same. We can see that by not needing to go to such limits, Public-Key encryption contributes to the meeting of both goals in that basically any valid user will be able to enjoy a secure connection.

An Example taken from http://info.frontlinedefenders.org/manual/en/esecman/chapter2_4.html: You have a message that you wish to send to me encrypted. First, I must give you a copy of my public key. You use this public key to encrypt the message and send it back by email or other means. Only I will be able to decrypt this message since only I have the missing link – my private key.

A trusted computing base (TCB) of a computer system is the set of code that must be correct to preserve complete mediation. All software, hardware, and firmware components are critical to its security in the sense that bugs occurring inside these components might jeopardize the security properties of the entire system. By contrast, parts of a computer system outside the TCB supposedly cannot misbehave in a way that would leak any more privileges than was granted to them in the first place in accordance to the security policy. Wikipedia, TCB

Ken Thompson is an American pioneer of computing and co-inventor the UNIX operating system. Ken and Dennis Ritchie received the Turing Award for their development of generic operation systems and for the implementation of the UNIX operating system. In his acceptance speech, "Reflections of Trusting Trust" , he presented the “backdoor” attack. Here, Ken explains how he creates a backdoor into the UNIX operating system allowing him to log into any UNIX system in the world. The moral of this speech is for programmers to always question the security of a system and to never trust any code besides their own. Ken Thompson