🔥 SCHA + STSP communication security protocol
Go to file
Adrien Marquès 8c65fa33a7 server challenge typo 2019-08-02 08:28:45 +00:00
client gofmt, govet, .. 2018-09-06 16:41:03 +02:00
cmd gofmt, govet, .. 2018-09-06 16:41:03 +02:00
context gofmt, govet, .. 2018-09-06 16:41:03 +02:00
internal gofmt, govet, .. 2018-09-06 16:41:03 +02:00
server gofmt, govet, .. 2018-09-06 16:41:03 +02:00
.gitignore [gitignore] added .vscode folder 2018-04-21 00:01:29 +02:00
PROTOCOL.md server challenge typo 2019-08-02 08:28:45 +00:00
README.md gofmt | update readme (client cli) + minmod 2018-07-25 14:19:44 +02:00

README.md

SCHA/STSP

Copyright (C) 2017 xdrm-brackets

Go version Go Report Card Go doc

Overview


This software defines and uses its own protocol which bundles 2 technologies :

  • Stateless Cyclic Hash Algorithm
  • Stateless Time Scrambling Protocol

It is meant to be used over request/response stateless networking and has been designed with HTTP in mind. The protocol only covers the generation and management of a pair of tokens which are hexadecimal strings. These are sent inside each request and a pair also has to be sent back to the sender. These tokens are mainly sent in the HTTP Authorization header for HTTP requests and responses.

Features

Beyond security issues, this protocol has some additional features :

  • Trust Chain - Each exchange between the server and the client is bound to the previous one. Each request is unique and can only give information about previous ones, not future ones. This principle ensures the server that no-one can be faking the client (unless someone has access to its key).

    If an attacker can guess (e.g. bruteforce) a successful request and gain access to the server - if he hasn't the client's key - it is fairly impossible that he also guesses the next request.

    A resynchronization protocol is featured in this package in order for a client to regain ownership on the trust chain if lost (by network issue or by an attack).

  • Time-awareness - A request is only valid a short amount of time after its generation. This amount is usually the maximum transmission time.

    Any MITM that catches the client's request to change its content only has a minimum time to forward it. As a result - if the amount is well chosen - any request modification is blocked by the time it takes.

  • [TODO]

Security

The aim of this package is to provide a secure authentication system between a server and its clients. Secure is defined as follows :

  • No man-in-the-middle (MITM) can gather enough information to fake any client. Every data sent over the network is the result of one or more one-way algorithms.
  • Neither a protocol understanding nor the source code can help an attacker fake a client or find useful information among requests.
  • The server has no secret key other than the synchronization key (used once to bind the client). The server has no clue what each client's key is, in fact it knows as much as a MITM.

Requirements


You need a recent machine with go installed.

This package has not been tested under the version 1.10.

Installation


Download the package with go get :

go get git.xdrm.io/logauth/schastsp

Build the executables :

go install git.xdrm.io/logauth/schastsp/cmd/client;
go install git.xdrm.io/logauth/schastsp/cmd/server;

The executables are now available in your $GOBIN (i.e. $GOPATH/bin) folder.

Client


1. Usage

client <command> [options]

Available commands are :

  • -req generates a new request into standard output
  • -res reads and manages a response from standard input
  • -sync generates a synchronization key into standard output (i.e. resets the system)

Available options are :

  • -file sets the folder where the keys are (or will be) stored.

  • -win sets the window value (in milliseconds). Typically the maximum transmission time.

  • -min sets the minimum cyclic-hash depth.

  • -max sets the maximum cyclic-hash depth.

  • -thr sets the cyclic-hash threshold. This value represents at which offset of the key's TTL the key will be generated. It also corresponds to the number of time the client can desynchronize before becoming impossible to synchronize again.