# Lösungsvorschlag Information Security 2006

## Inhaltsverzeichnis

## Security Bootstrapping

**a)**
To form a secure channel from A to B, there must be a path from A to B with a . an A's side along the path and B has to trust all entities along this path (except A) and symmetrically a path from B to A must exist with the same properties.

There exists a path from A to B namely

A .-> F_AB .-> H_AB .=. E_AB .-> B

This is a valid path since B trusts all entities.

There's no such path however from B to A. All paths must start with

B .->. K_a

(since B ->. E_AB has the . not on B's side and J_B is not trusted by A)

The next step is only K_A .-> D_a. From here there are 2 paths

i) D_A .-> C_AB

but this is a dead end, since C_AB ->. has the . on the wrong side

ii) D_A .-> E_AB .=. H_AB

but from there on, there's no path to A since G_B is not trusted by A an H_AB ->. F_AB has the . on the wron side.

**b) **

i) The first change is

A <-. C_AB

Now there's a path

B .-> K_A .-> D_A .-> C_AB .-> A

and A trusts all entities along the path except B. The path from A to B is left unchanged. Hence there's a secure channel A .<->. B

ii) The second change is that A trust G, therefore there's a path

B .->. K_A .-> D_A .-> E_AB .=. H_AB .-> G_AB .-> A

and a A trusts all entities along the path except B. The path from A to B is left unchanged. Hence there's a secure channel A .<->. B

## Trust, Authenticity, and Recommendations

No additional arrows are needed:

Aut_A,C:

Aut_A,T Trust_A,T,2 Cert_T,W |- Aut_A,W

Aut_A,T Trust_A,T,2 Cert_T,V |- Aut_A,V

Aut_A,V Trust_A,V,2 Rec_V,W,1 |- Trust_A,W,1

Aut_A,W Trust _A,W,1 Cert_W,Y |- Aut_A,Y

Aut_A,T TrustA,T,2 Rec_T,Y,1 |- Trust_A,Y,1

Aut_A,Y Trust_A,Y,1 Cert_Y,C |- Aut_A,C

Aut_A,B:

Aut_A,V Trust_A,V,2 Cert_V,X |- Aut_A,X

Aut_A,S Trust_A,S,2 Rec_S,U,3 |- Trust_A,U,2

Aut_A,S Trust_A,S,2 Cert_S,U |- Aut_A,U

Aut_A,U Trust_A,U,2 Rec_U,X,2 |- Trust_A,X,2

Aut_A,X Trust_A,X,2 Cert_X,B |- Aut_A,B

I don't think that A, B is possible. In particular, the second derivation above is incorrect, since you could only derive Trust_A,U,1. Using this, you don't get trust in X. I suggest changing Trust_A,S,2 to Trust_A,S,3. If this is the case, we can use the derivation above (also change derivation 4, same mistake).

-- Duh

I don't think A, B is possible, either. My suggestion would be to add an arrow Rec_V,X,1. This would make the following derivation sequence possible:

Aut_A,B:

Aut_A,T Trust_A,T,2 Cert_T,V |- Aut_A,V

Aut_A,V Trust_A,V,2 Cert_V,X |-> Aut_A,X

Aut_A,V Trust_A,V,2 Rec_V,X,1 |-> Trust_A,X,1

Aut_A,X Trust_A,X,1 Cert_X,B |-> Aut_A,B

-- rueeggn

I agree because you can not derive trust if the recommendation and your trust in the target comes from different entities. --Joker 21:18, 18. Aug. 2010 (CEST)

## Kerberos

**a)**
There are 3 pre-shared keys necessary

A .=. AS AS .=. TGS P .=. TGS

**b)**

1.

AS .=t4=. A

2.

AS .=t4=. TGS t5 >= t4

3.

AS .-t5->. A AS .-t4->. TGS A trusts AS TGS trusts AS

4.

A .=. TGS t5 > t1

This might be a little detail, but the insecure channels are missing in the shared key transformations... Edit: 5.8.2010 Luftibus

**c)**

After the 4th step in b) there's a secure channel between A and TGS. TGS now can give to A 2 informations

i) the identity of P (namely it's public key) ii) a ticket granting use of P encrypted with the pre-shared key iii) P .=. TGS (A can't read this ticket) In this ticket there's information about the identity of A (namely it's public key)

Now A can go to P give it the ticket that was received from TGS and they can create a key by a key agreement protocol (RSA or Diffie-Hellmann). This is possible since A is authenticated to P (via the ticket that only P can read) and P is authenticated to A (since the identity of P is known to A)

hence

A .-> P => A .=. P P .-> A

I am not sure about this solution. I believe that the transformation is not the one they would have expected. I rather think that this would be correct: First A secure channel between TGS and P is established by using the shared key. TGS.=t1=.P TGS -t2-> P t2>=t1 ======> TGS.-t2->.P

Then using the Key Distribution Transformation the shared secret key between P and A is established. (too lazy to write that down) Edit: 5.8.2010 Luftibus

## One-Way Functions

**a)**
Assume g(x, x') is not a one way function. Then there would be a algorithm A which calculates x and x' for a given g(x, x'). Since g(x, x') = f(x) one could use A to find x for f(x) -> contradiction. Assume for any x* != x' g(x, x*) != g(x, x') then f(x) != f(x) -> contradiction. Therefore g(x, x*) = g(x, x') and g is not collision resistant.*

**b) **
h is no one way function, because for a value (a,b), one could easily give an efficient algorithm G that works as follows:

i) since h(a,b) = (f(a),a) one can easily compute a (a simple cut of the message. the length of f(a) is known, according to kerckhofs principle, it is n)

ii) form a random c in {0,1}^2n

it now is

G(h(a,b)) = (a,c)

and thus

h(G(h(a,b))) = h(a,c) = (f(a),a)

h' is a one way function. if there were an algorithm to get (x,x') from (f(x),x') you could use it to calculate any x for a given f(x) by just adding a random x' as 2. factor. but since there cannot exist such an algorithm, h' is also one way.

## Trust-Based Security Transformations

a)

- online: T distributes a sessionkey to a and b
- offline: PKI certificates

b)

- inline: T can just read the messages before forwarding
- online: T would have to intercept the messages (T knows the sessionkey)
- offline: T could sign Eve's PK in Alice's name.

c) offline, because in the other two cases T actually knows the key(s) that are used between A and B. also because T doesn't know when A and B actually want to talk to each other.

## Digital Signatures

a)

A t1.->t2 B A t3->t4 B => A t3.->t4 B t3 > t2

Digital signatures can preserve authencity of a channel over time.

b) Ausgegangen wird von einem bestehenden authentischen channel von A nach B (wie in der digital signature transformation).

1. Sende den public encryption key:

A t1 .-> t2 B A t4 <- t3 B ==> (2.12) A t4 .<- t3 B t3 > t2

2. Key transport:

A .<- B ==> (2.5) A .<= B

3. MAC:

A t1 .<= B A t2 -> t3 B ==> (2.8) A t2 .-> t3 B t2 >= t1

c) Aus Wikipedia:

Aus den Signaturen und der Nachrichten x und y lässt sich die Signatur von xy durch die Formel

```
```

berechnen, ohne dass dabei der private Schlüssel ermittelt wird bzw. werden kann.

## Diffie-Hellman key-exchange

a)

Let g and p be publix constants, where p is a big enough prime number and g is in the natural numbers (the base)

A B x_a in {0,...,p-2} x_b in {0,...,p-2} y_a = g^x_a (mod p) y_b = g^x_b (mod p) y_a -----------------------> y_b <----------------------- k_AB = y_b ^ x_a (mod p) k_BA = y_a ^ x_b (mod p)

where

k_AB = y_b ^ x_a = (g^x_b)^x_a = (g^x_a)^x_b = y_a ^ x_b = k_BA (mod p)

(see script by Maurer p.51)

b)

A .-t1-> B B .-t2-> A => A .=t3=. B t3 > t1 t3 > t2

## Mandatory access control: Bell-LaPadula

// justification? -> ACK :-)

a) neither

b) read

c) read

d) neither

e) write

## Access control and cryptography

a)

- How to store and retrieve private keys for individual users -> trusted party (e.g. root)
- How to share files between multiple users -> shared pub/private key pair
- When someone has only execution rights on a file -> trusted virtual machine

b) perhaps by having multiple people sharing the same user or multiple users in the same role (by rbac). Or: When the intruder can gain physical access to the hard disk?

## Anonymity via proxies

a)

A proxy is like a relay between to parties. Each party talks to the proxy stating what he should tell the other party. The proxy then tells this information in his (proxies) name. The answer goes to the proxy which then get's relayed the same way. So either side can't decice who asked the question and who gave the answer.

b)

The message get's encrypted with the public-key of the last proxy in the chain, then with the second public-key and so forth. The message then get's sent to the first proxy. the proxy can only decipher the outermost message (he can't decice what the message says). He then sends the message to the next proxy in the chain and so forth. The last proxy can see the message which then get's forwarded to the recipent. The last proxy doesn't know (similar like all the other proxies in the chain with the exception of the first one, who the message originated from). the answer can be send through a similar chain.

c)

the length of the message does not differ much if it's encrypted or not. It also is clear on which port (for the case of TCP) the message is going (so we can know if it is a mail programm talking or not). Also we could conclude from the length of the message what it says (when we know all messages originating from A, like "yes", "no", "sure" they have all different length but even if they are encrypted we still know which one was sent).

traffic analysis can be avoided by introducing dummy messages as well as padding the messages all to the same size (padded with 0's to length 128 for example).