gistfile1.txt

WebFusion Client Coupling Protocol 1.0
Modified from MessHall 1.1 protocol.

Part 1: Common format of the package

As described in C struct:

typedef struct __MHBinaryPackage
{
  uint32_t magic;			// = 0xEA5EEA5E ("Ease, ease")
	uint16_t flags;			// Not used for now, unless indication failure.
	uint16_t operation;		// Subprotocol type really.
	uint64_t payload_length;	// Obvious thing.
	uint8_t  payload[];		// Real payload.
} MHBinaryPackage;

Part 2: Device discovery and key exchange.

This is the procedure how the host (e.g. a PC) discover a device (e.g a smartphone) and
safely performs a key exchange with the device with user intervention and with
confirmation in place.

Packet sequence: (H = Host, D = Device)
Seq.	Direction	Proto.	Description	(Described in JSON, transmitted in binary)
1:	H --> D (Bc.)	UDP (B)	Host hello:	{operation: hello}
2:	H <-- D		UDP	Device hello.	{operation: alloc, name: (string)}
3:	H --- -		---	User choose the device from a list.
4:	H --> D		TCP	Connection.	{operation: init}
5:	H <-- D		TCP	Challenge.	{operation: challenge,
						      data: (256-bit random: R1)}
6:	- --- D		---	Device display connection confirmation code.
7:	H --- -		---	User type in the code on host.
8:	H --> D		TCP	Challenge response.
						{operation: challengeResponse,
						      data: AES256(key: SHA256(code),
								  data: R1)}
9a:	H <-- D		TCP	Connect establishment.
						{operation: challengeOK} (if the response
									  matches, or)
9a:	H <-- D		TCP	Connect rejection.
						{operation: challengeRejected}
10:	H --> D		TCP	Key exchange.	{operation: keyAssign,
						      data: AES256(key: SHA256(code),
								  data: (256-bit R2))}
11:	H <-- D		TCP	Key confirm.	{operation: keyConfirm,
						      data: AES256(key: R2,
								  data: code+string)}
12a:	H --> D		TCP	Key confirm rejected.
						{operation: keyRejected} (if code mismatch
									  or)
12b:	H <-> D		TCP	Communications are now encrypted using R2 as AES256 key.
						{operation: (according to the payload),
						      data: AES256(key: R2, data:…)}

Security is based on the difficulty of breaking AES256 algorithm with plaintext/ciphertext
pair only, since the code is never transmitted over the air.

Part 2: Session transfer.

Session transferring is simpler as a simple transfer of all involved HTTP cookies. It is
done by transferring all cookies encoded as a JSON dictionary. The transfer is done over
the previously established encrypted channel.

Part 3: Notification transfer.

Transferring notifications would require transferring data that is not usually cross-
platform compatible. This would require a rewritten FKJSONKeyedArchiver &
FKJSONKeyedUnarchiver classes, as well as a notification capture & re-transmit code. This
feature is largely debug-only, thus can be done in ad-hoc fashion by adding categories
to existing classes.