logauth
/
schastsp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

updated PROTOCOL.md (WIP) > began actual protocol

This commit is contained in:
Adrien Marquès 2018-09-05 17:22:51 +02:00
parent 09d7a6aa12
commit a386ccd5a1
1 changed files with 46 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
PROTOCOL.md
View File

@ -131,19 +131,19 @@ The receiver has to guess $t_s$ with the following steps:
| 1 | receive the sender's time parity | $Receive \ m_s$ |
| 2 | process the receiver's time id | $t\_r = \mid \frac{t_{now}^r}{W} \mid $ |
| 3 | process the receiver's time parity | $m_r = t_r \mod 2$ |
| 4 | Try to guess the sender's time id | $t_{s2} = t_r - \parallel m_s - m_r \parallel $ |
| 4 | Try to guess the sender's time id | $t'_s2 = t_r - \parallel m_s - m_r \parallel $ |
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 \leq t\_{now}^s + W \implies 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.
As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to guess the token nor $h(t_s)$ without the other.
As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to guess neither the token nor $h(t_s)$ without the other.
**Explanation**
* 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 window 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$.
* 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$
@ -194,93 +194,74 @@ For a given key, <u>every token sent has a lower nonce</u> $n$ than every other
## Protocol definition
Each request will hold a <u>pair of tokens</u> $(x_1, x_2)$. If the server's check fails (*i.e. the client is not authenticated*), it will send back to the client a <u>pair of tokens</u> $(y_1, y_2)$ for resynchronization.
Each request will hold a <u>pair of tokens</u> $(x_1, x_2)$. If the server's check fails (*i.e. the client is not authenticated*), it will send back to the client a <u>pair of tokens</u> $(y_1, y_2)$ for resynchronization purposes.
Each token has a size defined by the *hash function*, which is `sha512` for this specification ; the size is then 512 bits.
> For readability purposes, the tokens are sent as their hexadecimal representation ; each token is then a string of 128 characters.
### 1. Request
### 1. Send the request
This case is the default where $i$ is far from $1$ so there is no key generation to do.
This case is the default where $i$ is far from $1$ so there is no key generation or synchronization to do.
| Step | Description | Formula |
|:----:|-------------|:--------|
| `c1` | Decrement the shifting nonce | $i = i - 1$ |
| `c2` | Calculate the one-time token $T_C$ | $T_C = h^{i}(K)$ |
| `c3` | Get the current window id $t_C$ | $t_C =\ \mid \frac{t_{now}}{W} \mid$ |
| `c4` | Calculate $m_C$, the parity of $t_C$ | $m_C = t_C \mod 2$ |
| `c5` | Calculate the time hash $h_{t_C}$ | $h_{t_C} = h(t_C)$ |
| `c6` | Calculate $x_1$, the scrambled *request token* | $x_1 = T_C \oplus h_{t_C}$ |
| `c7` | Calculate $x_2$, the next token + time parity | $x_2 = x_1 \oplus m_C$ |
| `c2` | Calculate the one-time token | $T_c = h^{i}(K)$ |
| `c3` | Get the current time id | $t\_c =\ \mid \frac{t\_{now}}{W} \mid$ |
| `c4` | Calculate the parity of $t_c$ | $m_c = t_c \mod 2$ |
| `c5` | Calculate the time hash $h_{t_c}$ | $h_{t_c} = h(t_c)$ |
| `c6` | Calculate $x_1$, the scrambled *request token* | $x\_1 = T\_c \oplus h\_{t\_c}$ |
| `c7` | Calculate $x_2$, the scrambled *next token* | $x_2 = x_1 \oplus m_c$ |
**Security** : We process a one-time pad between $T_C$ and $h_{t_C}$ it is crucial that both values have the same size of $L$ bits. It makes $T_C$ impossible to extract without having the value $h_{t_C}$, this property applies in both ways.
**Security** : We process a one-time pad between $T_c$ and $h_{t_c}$ it is crucial that both values have the same size of $L$ bits. It makes $T_c$ impossible to extract without having the value $h_{t_c}$, this property applies in both ways.
**Short formulas**
| Field to send | Short formula |
| Field | Short formula |
| :-----------: | ------------------------------------------------ |
| $T_{req}$ | $h^{i}(K) \oplus h(\mid\frac{t_{now}}{W}\mid)$ |
| $m_C$ | $\mid\frac{t_{now}}{W}\mid \mod 2$ |
| $t_c$ | $\mid\frac{t_{now}}{W}\mid$ |
| $x_1$ | $h^{i}(K) \oplus h(t_c)$ |
| $x_2$ | $x_1 \oplus (t_c \mod 2)$ |
> Note
>
> - In order to send all the data in one request, for instance you can simply concatenate the 2 variables.
Send $(x_1, x_2)$.
### 2. Receive the request
### 2. Response
<u>Received data</u>
- $T_{req}$ the received request token
- $m_C$ the received time id parity
The server receives $(x_1, x_2)$. It does have to :
1. Guess the client's time id to un-scramble the token
2. Check the token
| Step | Description | Formula |
|:----:|-------------|---------|
| `s1` | Store the reception time window id $n'$ | $n' = \mid \frac{t_{now}}{W}\mid$ |
| `s2` | Calculate $m_S$, the parity of $n'$ | $m_S = n' \mod 2$ |
| `s3` | Use $m_C$ to try to correct the reception window id and guess the request time id | $n_S = n' - \parallel m_C - m_S \parallel$ |
| `s4` | Calculate the time hash $h_{n_S}$ | $h_{n_S} = h(n_S)$ |
| `s5` | Cancel $h_{n_S}$ to extract $T_{C'}$ | $T_{C'} = T_{req} \oplus h_{n_S}$ |
| `s6` | Check if $T_{C'}$ matches $T_S$ | $T_{C'} = T_S ?$ |
> If $T_{C'} = T_S$, $S$ can consider that $C$ sent the request $0$ to $(W + \frac{W}{2})$ seconds ago.
**Steps explanation**
- `s1` - If $C$ and $S$ have the same values for $K$ and $n^1$, $f(K,n^1)$ must result in the same output; in other words $T_C=T_S$.
- `s3`/`s4` - $\parallel m_C - m_s\parallel$ is the difference between $m_C$ and $m_S$.
- If the receiver time window id ($n'$) is the same as the sender ($n_C$)
$n'=n_C \implies m_S=m_C$
$m_C=m_S \implies \parallel m_C - m_S\parallel = 0$
$n_S = n_C - 0$
$n_S=n_C$, the time ids are the same, $S$ can now unscramble the request to check the token
- If the receiver time window if further the sender by $1$
$n'=n_C+1 \implies \parallel m_C - m_S \parallel = 1$
$n_S = n_C + 1 - 1$
$n_S = n_C$, the time ids are the same, $S$ can now unscramble the request to check the token
- If the receiver time window if further the sender by $2$ or more, let $k \in \N$
$n'= n_C+2+k \implies \parallel m_C - m_S\parallel \in \{0,1\}$
$- \parallel m_C - m_S\parallel \in \{-1,0\}$
$n_S \in \{n_C + 2 + k - 1, n_C + 2 + k + 0\}$
$n_S \in \{n_C + k + 1, n_C + k + 2\}$
$\rarr n_S = n_C + k + 1 \implies \forall (k\in \N), n_S \gt n_C$, the time ids differ, $S$ cannot extract $T_S$
$\rarr n_S = n_C + k + 2 \implies \forall (k \in \N), n_S \gt n_C+1$, the time ids differ, $S$ cannot extract $T_S$
- `s6` - By the *non-idempotency* (*i.e. $a\oplus b \oplus a = b$*) and *associativity* properties of the *XOR* operator, considering $h_{n_S}=h_{n_C}$:
$T_{C'} = T_{req} \oplus h_{n_S} = (T_C \oplus h_{n_C}) \oplus h_{n_S}$
$h_{n_S} = h_{n_C} \implies T_{C'} = T_C \oplus h_{n_C} \oplus h_{n_C}$
$T_{C'} = T_C$, the one-time token of $C$ have successfully been extracted
- `s7` - If $K$ and $n^1$ are the same on both machines, $T_S=T_C$. Furthermore, if the time ids are the same (*c.f. step `s6`*) the 2 tokens should match.
|:----:|-------------|:--------|
| `s1` | Extract the client's time parity | $m_c = x_1 \oplus x_2$ |
| `s2` | Get the current time id | $t\_s =\ \mid \frac{t_{now}}{W} \mid$ |
| `s3` | Calculate the parity of $t_s$ | $m_s = t_s \mod 2$ |
| `s4` | Guess the client's time id | $t'_c = t_s - \parallel m_s - m_c \parallel$ |
| `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}$ |
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.
**Short formulas**
​ The whole unscrambling process can be shortened into the following formula resulting in $0$ if the client is authenticated.
$T_{req} \oplus h(\mid \frac{t_{now}}{W}\mid - \parallel m_C - (\mid \frac{t_{now}}{W}\mid \mod 2) \parallel) \oplus f(K, n^1)$
$$x\_1 \oplus h(\mid \frac{t\_{now}}{W}\mid - \parallel (x\_1 \oplus x\_2) - (\mid \frac{t\_{now}}{W}\mid \mod 2) \parallel) \oplus T$$
| Step | Description | Formula |
|:----:|-------------|:--------|
| `rs1` | Get the current time id | $t\_s = \mid \frac{t\_{now}}{W} \mid$ |
| `rs2` | Calculate the parity of $t_s$ | $m_s = t_s \mod 2$ |
| `rs3` | Calculate the time hash $h_{t_s}$ | $h_{t_s} = h(t_s)$ |
| `rs4` | Calculate $y_1$, the recovery hash | $y\_1 = T \oplus h\_{t_s}$ |
| `rs5` | Calculate $y_2$, used for parity | $y_2 = y_1 \oplus m_s$ |
Send $(y_1, y_2)$.