From f567b75f4ec553a2378150bc56237cea70e7df7e Mon Sep 17 00:00:00 2001 From: xdrm-brackets Date: Thu, 6 Sep 2018 15:52:31 +0200 Subject: [PATCH] simplified protocol --- PROTOCOL.md | 102 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 76 insertions(+), 26 deletions(-) diff --git a/PROTOCOL.md b/PROTOCOL.md index 05c4298..41604b4 100644 --- a/PROTOCOL.md +++ b/PROTOCOL.md @@ -40,8 +40,11 @@ A better solution would be to generate a private key on each client and use it t This document will define and bundle 2 distinct protocols to make up a token system that implements the previous statements. -1. a Stateless Time Scrambling Protocol to take care of the request's expiration over time. -2. a Stateless Cyclic Hash Algorithm to generate several public tokens from a private key in a way that no clue is given over published tokens (*i.e. one-way function*). +1. a Stateless Time Scrambling Protocol to take care of the request's invalidation over time. +2. a Stateless Cyclic Hash Algorithm to use a private key as a one-time token generator in a way that no clue is given over published tokens (*i.e. one-way function*). +3. A key renewal mechanism in a way that no clue is given over neither the old nor the new key. +4. A rescue protocol to resynchronise the client with a new key in a way that no clue is given over the network and the client has to process a "proof of work". + ## General knowledge & Notations @@ -52,23 +55,17 @@ This document will define and bundle 2 distinct protocols to make up a token sys | $\parallel a\parallel $ | The absolute value of $a$ ; *e.g.* $\parallel -12 \parallel = 12$ | | $\mid a \mid$ | The integer value of $a$ ; *e.g.* $\mid 12.34 \mid = 12$ | | $a \oplus b$ | The bitwise operation XOR between binary words $a$ and $b$ | +| $a \And b$ | The bitwise operation AND between binary words $a$ and $b$ | | $h(m)$ | The digest of the message $m$ by a (consistent) secure cryptographic hash function $h()$ ; *e.g. sha512* | | $h^n(m)$ | The digest of the $n$-recursive hash function $h()$ with the input data $m$ ;
$h^2(m) \equiv h(h(m))$, $h^1(m) \equiv h(m)$, and $h^0(m) \equiv m$. | -| $a \mod b$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ | +| $a \ \mathbb{Z}_{(b)}$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ | | $t_{now}$ | The current *Unix Timestamp* in seconds | - - -##### Entities - -- A client $C$ (*typically a client*) -- A server $S$ (*typically a server*) - ## Variables The whole system share a common **context**, each client holds a **private keyset**, and the server stores the **last valid token** of each client. -##### Common context +#### 1. Common context These variables are both on the server and clients. They are specific to the server so each client must match its values. These variables shape the system's **context** $(W, min, belt, max)$. @@ -79,7 +76,7 @@ These variables are both on the server and clients. They are specific to the ser | $sec$ | security range | A number that is used to resynchronize the client if there is a communication shift (*e.g. lost request, lost response, attack*). It corresponds of the number of desynchronizations the client can handle before never being able to gain the authentication again. | | $max$ | maximum nonce | A number that is used to cap the value of client's nonces. A too high value will result on keys that will never be replaced, thus making them open to long-processing attacks (*e.g. brute-force*). | -##### Client keyset +#### 2. Client keyset Every client holds a **keyset** $(K, n, s)$. It represents its private key and is used to generate the tokens. The secure hash function is extended as a **one-way function** to generate all the tokens from the keyset. @@ -87,19 +84,72 @@ Every client holds a **keyset** $(K, n, s)$. It represents its private key and i |:--------:|:----:|:------------| | $K$ | private key | A secret binary data that must be large and *random* enough not to be brute forced. | | $n$ | key nonce | A number that is decremented before each request. Before $n$ reaches 0, a new keyset must be generated. | -| $s$ | key state | A number that reflects the state of the keyset. It is used to know what to do on the **next request** :
- $0$ : normal request
- $1$ : will use the new key
- $2$ : resynchronization processed, waiting for the server's acknoledgement | +| $s$ | key state | A number that reflects the state of the keyset. It is used to know what to do on the **next request** :
- $0$ : normal request
- $1$ : will switch to the new key
- $2$ : rescue proof of work sent, waiting for the server's acknowledgement | -The token generation algorithm is : -1. Decrement $n$ -2. Process token $= h^n(K)$ - -##### Server variables +#### 3. Server variables | Notation | Name | Description | |:--------:|:----:|:------------| | $T$ | last valid token | The server stores the last valid token from the client to check the next one. | -If a client sends its token $h^n(K)$ ; if valid the server stores it inside $T$. Note that for the system's **initialisation**, the server has to be given $T = h^{n-1}(K)$. + +## Protocol + +#### 1. Client authentication + +In each request, the client will send a pair of tokens $(x_1, x_2)$ : +- $x1$ will hold the current one-time token +- $x2$ will hold data to check the next one-time token to be used + +The client's current keyset has 3 states : +- `normal` - default authentication algorithm. +- `switch` - default algorithm variation to switch to a new keyset when the current one is consumed. +- `rescue` - process the proof of work after receiving the server's challenge when there is a desynchronisation and generate a new keyset. + +When the client switches to a new key, it has to the new keyset along the current one, in order not to lose its authentication if the network fails. +- $(K,n,s)$ - the current keyset +- $(K',n',s')$ - the new keyset + +##### a. `normal` protocol + +1. Decrement $i$ +2. $t\_c = \mid \frac{t\_{now}}{W}\mid$ +3. $x\_1 = h^{n}(K) \oplus h(t\_c)$ +4. $x\_2 = x\_1 \oplus (t\_c \ \mathbb{Z}\_{(2)})$ + +Send $x_1$ and $x_2$. + +If $i \leq min+sec$, go to `switch` protocol. + +##### b. `switch` protocol + +1. $t\_c = \mid \frac{t\_{now}}{W}\mid$ +2. $x\_1 = h^{n}(K) \oplus h(t\_c)$ +3. Generate $(K',n',s')$ in a way where the following condition is met : + - $[(h^n(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $ +4. $x\_2 = h^{n'}(K') \oplus h(t\_c)$ + +Send $x_1$ and $x_2$. + +#### c. `rescue` protocol + +The rescue protocol is processed when receiving $y_1$ and $y_2$ from the server instead of the standard response. + +1. $m_s = y_1 \oplus y_2$ +2. $t\_c = \mid \frac{t\_{now}}{W} \mid $, $m\_c = t\_c \mathbb{Z}\_{(2)}$ +3. $t'\_s = t\_c - \parallel m\_c - m\_s\parallel$ +4. $T = x\_1 \oplus h(t'\_s)$ +5. Find $N \in [min ; n-min[,\ h^{N}(K) = T$. +6. $x\_1 = h^N(K) \oplus h(t\_c)$ +7. Generate $(K',n',s')$ in a way where the following conditions are met : + - $[(h^N(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $ + - $[(h^N(K) \oplus h^{n'}(K')) \And 11110000] \ \mathbb{Z}\_{(3)} = 2$ +8. $x\_2 = h^{n'}(K') \oplus h(t\_c)$ + +Send $x_1$ and $x_2$. + + +## blablabla ##### Check a token @@ -135,7 +185,7 @@ The receiver has to guess $t_s$ with the following steps: As a result, the receiver will only be able to retrieve the sender's time id if the reception time is at most $W$ seconds after the sending time : -$$t\_{now}^r \leq t\_{now}^s + W \implies t\_s = t'_s2$$ +$$t\_{now}^r \in [t\_{now}^s ; t\_{now}^s + W] \Longrightarrow t\_s = t'_s2$$ In practice, the time id is **hashed** and used to achieve a [one-time pad](https://en.wikipedia.org/wiki/One-time_pad) with the token. Because they both result from the same hash function their sizes are the same. @@ -145,11 +195,11 @@ As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to * The time id corresponds to the index of the time slice where slices are $W$ seconds wide. By dividing the time in slices of $W$ seconds, if we process the same calculation at an interval of $W$ or less seconds, we will have either the same result or a result greater by 1. * The time id parity $m_s$ allows us to adjust the receiver's time id $t_r$ when it receives the request. This difference of 1 second is caused by the division of time in slices, the precision is also divided by $W$. - - $ t_{now}\mod W = 0 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid $; no need for adjustment - - $ t_{now}\mod W = 1 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$ - - $ t_{now}\mod W = 2 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$ - - $ ... $ - - $ t_{now}\mod W = (W-1) \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$ + - $t\_{now}\mod W = 0 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid $; no need for adjustment + - $t\_{now}\mod W = 1 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$ + - $t\_{now}\mod W = 2 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$ + - $...$ + - $t\_{now}\mod W = (W-1) \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$ ## Protocol properties @@ -243,7 +293,7 @@ The server receives $(x_1, x_2)$. It does have to : | `s5` | Calculate the time hash $h_{t'_c}$ | $h_{t'_c} = h(t'_c)$ | | `s6` | Extract the token $T'_c$ | $T'\_c = x_1 \oplus h\_{t'\_c}$ | | `s7` | Extract the next token $T_{next}$ | $T\_{next} = x\_2 \oplus m\_c \oplus h\_{t'\_c}$ | -| `s8` | Check the token | $h(T'\_c) = T \implies T = T_{next}$ | +| `s8` | Check the token | $h(T'\_c) = T \Longrightarrow T = T_{next}$ | If the token is valid on step `s8`, the next validation token $T_{next}$ is stored and the request can be processed by the server. If the token mismatches, the recovery mode is enabled.