| 1 | |
|---|
| 2 | Keys: |
|---|
| 3 | |
|---|
| 4 | Users: |
|---|
| 5 | 1 bank account key: certificate is signed by bank |
|---|
| 6 | h host account key: certificate is signed by host |
|---|
| 7 | |
|---|
| 8 | Bank: |
|---|
| 9 | bank key: certificate signed by CA |
|---|
| 10 | |
|---|
| 11 | Hosts: |
|---|
| 12 | host key: certificate signed by owner |
|---|
| 13 | |
|---|
| 14 | SLS: |
|---|
| 15 | No key |
|---|
| 16 | |
|---|
| 17 | Operations: |
|---|
| 18 | Bank: |
|---|
| 19 | all use bank account key |
|---|
| 20 | |
|---|
| 21 | Host: |
|---|
| 22 | create_account uses bank account key |
|---|
| 23 | others use host account key |
|---|
| 24 | login uses reformed ssl key |
|---|
| 25 | |
|---|
| 26 | SLS: |
|---|
| 27 | clients are not authenticated |
|---|
| 28 | data put in SLS is signed by host |
|---|
| 29 | |
|---|
| 30 | SLS: |
|---|
| 31 | register() |
|---|
| 32 | data is signed with host key |
|---|
| 33 | can only register source address |
|---|
| 34 | |
|---|
| 35 | unregister() |
|---|
| 36 | authenticate with host key |
|---|
| 37 | |
|---|
| 38 | Bank: |
|---|
| 39 | all operations use bank account key |
|---|
| 40 | |
|---|
| 41 | Host: |
|---|
| 42 | create_account() |
|---|
| 43 | |
|---|
| 44 | |
|---|
| 45 | Typical sequence: |
|---|
| 46 | |
|---|
| 47 | 1) host - register -> SLS |
|---|
| 48 | |
|---|
| 49 | 2) host - unregister -> SLS |
|---|
| 50 | |
|---|
| 51 | 3) client - query -> SLS |
|---|
| 52 | |
|---|
| 53 | 4) SLS - query reply -> client |
|---|
| 54 | |
|---|
| 55 | 5) client - transfer -> bank |
|---|
| 56 | |
|---|
| 57 | 6) bank - transfer reply -> client |
|---|
| 58 | |
|---|
| 59 | 7) client - create account -> host |
|---|
| 60 | |
|---|
| 61 | 8) host - create account reply -> client |
|---|
| 62 | |
|---|
| 63 | 8) |
|---|
| 64 | |
|---|
| 65 | Attacks: |
|---|
| 66 | 1) MIM on 1), substitute self as owner, different host key |
|---|
| 67 | difficult for attacker to claim IP address |
|---|
| 68 | mitigated if user caches host keys |
|---|
| 69 | user should consider (owner, IP) tuple for reputation |
|---|
| 70 | |
|---|
| 71 | 2) 1) with own machine, but substitute other user as owner |
|---|
| 72 | |
|---|
| 73 | 3) Spoof 2), Dos |
|---|
| 74 | difficult for attacker to claim IP address |
|---|
| 75 | prevented because 2) requires host authentication |
|---|
| 76 | |
|---|
| 77 | 3) MIM on 3), substitute false information |
|---|
| 78 | |
|---|
| 79 | |
|---|
| 80 | ------------------------------------------------------------------------------ |
|---|
| 81 | |
|---|
| 82 | Simplified xml-rpc security: |
|---|
| 83 | |
|---|
| 84 | Attacks: |
|---|
| 85 | 1) modification |
|---|
| 86 | 2) spoofing |
|---|
| 87 | 3) replay |
|---|
| 88 | |
|---|
| 89 | Note, we do not require encryption. |
|---|
| 90 | |
|---|
| 91 | Assumptions: |
|---|
| 92 | C knows K_c, {K_c}^-1, K_s, and N_c |
|---|
| 93 | S knows K_s, {K_s}^-1, K_c, and P_c < N_c |
|---|
| 94 | |
|---|
| 95 | 1) C->S: C, S, N_c, M, MAC_{{K_c}^-1}(C, S, M, N_c) |
|---|
| 96 | 2) C<-S: C, S, N_c, R, MAC_{{K_s}^-1}(C, S, R, N_c) |
|---|
| 97 | |
|---|
| 98 | Notes: |
|---|
| 99 | a) when C sends 1), it increments N_c |
|---|
| 100 | |
|---|
| 101 | b) when S receives 1), it checks that N_c > P_c. If so, it sets P_c = |
|---|
| 102 | N_c, otherwise, it drops the message. |
|---|
| 103 | |
|---|
| 104 | c) when C receives 2), it checks that N_c == old N_c |
|---|
| 105 | |
|---|