Secure Data Transfer Protocol v0.1

Transcription

Secure P2P Data Transfer Protocol v0.1
Documentation v0.7
Secure Data Transfer Protocol v0.1
“These aren’t the data you are looking for.”
Felix Kletti - Thomas Picariello
Version 0.7
Bachelor Thesis Project
Spring semester 2014
1 • 52
Documentation v0.7
2 • 52
Documentation v0.7
Thanks
We would like to thank our thesis supervisor Prof. Dr.
Nouri for his patience, reachability, and dedication to let
us develop our project in our best interests. He did make
a good boss impersonation.
We also would like to thank the commissioned expert on
this project Dr. Reyes for the time he grant us and his
pertinent remarks on our work.
3 • 52
Documentation v0.7
4 • 52
Documentation v0.7
Table of Content
1.
Introduction .............................................................................................................................. 7
1.1.
Specifications ................................................................................................................... 7
1.2.
Planning............................................................................................................................ 7
1.3.
Administrative ................................................................................................................... 8
1.3.1.
Project management ................................................................................................. 8
1.3.2.
Contributors............................................................................................................... 8
2.
The Problem ............................................................................................................................ 9
3.
Protocol .................................................................................................................................. 10
3.1.
Versioning....................................................................................................................... 10
3.2.
Handshake ..................................................................................................................... 10
3.2.1.
Client Hello .............................................................................................................. 11
3.2.2.
AES key generation ................................................................................................ 11
3.2.3.
Public key exchange and authentication ................................................................ 12
3.2.4.
Handshake failure ................................................................................................... 13
3.3.
Packets ........................................................................................................................... 15
3.3.1.
Handshake .............................................................................................................. 15
3.3.2.
Generic packet ........................................................................................................ 16
3.4.
Encryption....................................................................................................................... 16
3.4.1.
Hybrid Cryptography ............................................................................................... 17
3.4.2.
RSA ......................................................................................................................... 19
3.4.3.
Advanced Encryption Standard (AES) ................................................................... 21
3.4.4.
Galois/Counter Mode (GCM) .................................................................................. 23
3.4.5.
Protocol specific GCM/AES IV generation ............................................................. 25
3.5.
Apps ............................................................................................................................... 27
3.5.1.
App Manager........................................................................................................... 27
3.5.2.
App Type Identifiers ................................................................................................ 28
3.6.
Links ............................................................................................................................... 29
3.6.1.
TCP: Transmission Control Protocol ...................................................................... 29
5 • 52
4.
3.6.2.
UDP: User Datagram Protocol ............................................................................... 29
3.6.3.
RTP: Real-Time transfer protocol ........................................................................... 29
Client Implementation ............................................................................................................ 30
4.1.
Structure ......................................................................................................................... 30
4.2.
User Interface ................................................................................................................. 31
4.3.
Contacts ......................................................................................................................... 38
4.4.
App Manager .................................................................................................................. 38
4.5.
Apps ............................................................................................................................... 40
4.5.1.
Messenger .............................................................................................................. 40
4.5.2.
Voice over IP ........................................................................................................... 41
4.5.3.
Video over IP........................................................................................................... 43
4.6.
Links ............................................................................................................................... 43
4.6.1.
Structure .................................................................................................................. 44
4.6.2.
Type ID’s ................................................................................................................. 44
4.7.
UPnP NAT Configuration ............................................................................................... 45
4.8.
Local data storage .......................................................................................................... 46
4.9.
Programing Tools ........................................................................................................... 47
4.9.2.
5.
Documentation v0.7
QtCreator ................................................................................................................ 48
4.10.
Libraries ...................................................................................................................... 49
4.11.
License........................................................................................................................ 50
Conclusion ............................................................................................................................. 51
5.1.
Perspectives ................................................................................................................... 51
APPENDIXES
A: T ESTS
B: REFERENCES
C: CONTINGENCY PLAN
6 • 52
1.
Documentation v0.7
Introduction
The Bachelor Thesis consists of a real-world problem which has to be analysed and solved in
collaboration with a professional contact.
This work aims to prove that the students are capable of working independently on technical
and economic issues, with concrete and realistic targets.
1.1.
Specifications
Mandatory goals:
● User data stored in a local encrypted database
● Encrypted data transmission (text, voice, images, video)
● Hybrid encryption through RSA/AES
● Optimisation of streaming protocols
● Client features: UPnP NAT auto-configuration
● Audit of performance and attack possibilities
● User interface ergonomy
Optional goals:
● Multiplatform Client Implementation (OSX, Linux, Android, iOS, ...)
● Truly Randomly Seeded - Pseudo Random Number Generator
● Distributed Public Key Servers
● Identity certification through a “Web of Trust”
● Application Programming Interface (API)
1.2.
Planning
Milestones
Definition of the Problem and the scope of the project
Researches for the documentation, start writing
Functional protocol on prototype implementation, contingency plan
Improving protocol and implementation, first expert meeting
Implementation, defining the test protocol
Final implementation, test, and expert review
Tests reports, final documentation review, presentation
Date
1st February
1st March
1st April
15th May
1st June
22th July
14th August
7 • 52
1.3.
Documentation v0.7
Administrative
1.3.1.
Project management
All the data and documents concerning this project are stored on a Google Drive which is
synced to a local folder on the computers of the people involved.
The latest version of this documentation can be accessed through this link:
https://docs.google.com/document/d/1jIlMR7D5hcNrIzGCNCag9FkZrjMCVYjjF70Arbrky4s/pub
The latest snapshot of the client source code is available on Github:
https://github.com/thomas-picariello/Secure-VoIP.git
Last but not least a presentation website is available at the following address:
http://web.fhnw.ch/technik/projekte/eit/Fruehling2014/KlePic/
1.3.2.
Contributors
Prof. Dr. Nouri Taoufik
Dr. Mauricio Reyes
Project Supervisor
Commissioned Expert
[email protected]
[email protected]
Kletti Felix
Picariello Thomas
Candidate
Candidate
[email protected]
[email protected]
8 • 52
2.
Documentation v0.7
The Problem
Voice and video communications as well as instant messaging over internet are becoming more
and more popular, allowing people staying in contact both in their private and professional life.
Teleworking, quick question/answer and professional video meetings greatly improve the
productivity of the workers. Families can easier stay in contact while being away from each
other. As this new way of communication spreads, some tools are becoming dominant in the
market, mostly because they are easy to use, generally free, and available on most devices.
Skype, Viber, Hangout, and Facetime are nowaday the most widespreads clients among private
users, and gain terrain on analog phones and PBX systems in the professionals users due to
their low costs and ease of deployment.
But they have a huge issue, which is slowly becoming a real problem: the communications they
carry are not private and they are proprietary centralized solutions.
As every communications going through those protocols are not encrypted, virtually anyone can
listen them, analyse them, or alter them. Hackers, industrial spying, and foreign secret services
have access to conversations that should remain private. The protocols specifications as well as
the client’s implementations are generally closed, preventing external reviews, and possibly
hiding security flaws that are not made public and generally not corrected.
Moreover they are centralized, meaning that some corporations have a full control over these
protocols and can shut them down at any moment without the consent of their users. They can
also harvest the data going through their servers or gather them through their closed-source
clients and analyse them for commercial or other purposes.
We think that the users should have full control over their communications, and that this control
should not come with extra costs or complications.
This project is an alternative to common real time multimedia communications protocols. It is
open-source and collaborative, anyone is welcome to review and improve it.
Open-source encrypted protocols exists for specific uses, such as voice communications or
instant messaging, but when it comes to installing them or using them they are often not
compatible with the platform the user has or require a compilation to be done. This makes them
frustrating to use and keeps most of the non-technical-expert users away.
The clients using this protocol should be multi-platform and user-friendly to allow anyone to use
it anywhere, in the easiest way.
9 • 52
3.
Documentation v0.7
Protocol
The Protocols main goal could be described as follows: Making exchanged Data over the
internet the most secure possible while maintaining the best possible transmission quality.
There are four key points that will be developed in order to explain what the protocol will do
exactly and what this implies for the security, usability and efficiency of the application.
- Versioning: How and why is the version numbers on different releases organized.
- Handshake: How the authentication and secure elements are exchanged on connection.
- Encryption: Why has the content to be encrypted and what method is used?
- Underlying protocols: what are the best use cases for TCP, UDP, and RTP, and how is the
main protocol able to be transmitted on all of them despite their different characteristics.
3.1.
Versioning
In order to keep track of the upgrades and other improvements that will inevitably occur in the
protocol specifications as well as the reference client implementation, a versioning convention is
established. It will be useful for users and developers to better follow the evolution of the code
and allow the protocol itself to better manage compatibility issues.
The version number is built with two components using the format: “a.b”, where:
a: 0-15
Major versions number. The major version is updated every time the downward
compatibility is broken.
b: 0-15
Minor version number. These versions do not break the compatibility with older versions.
Example:
The current version “0.1” will be followed by version 0.2, 0.3 and so on as improvements will be
made until the protocol itself will have to change in such a way that it won't any longer be
compatible with its precursor. Then the major version number will be incrementing resulting in
version 1.x.
3.2.
Handshake
The handshake is the most important and most critical part of the whole protocol. If the
handshake isn’t fully secure then the safety of the whole protocol is compromised.
Basically a Handshake consists of a few minimalistic data exchanges between clients in the
beginning of a communication session in order to define variables which will help to establish a
smooth communication on both sides, and eventually exchange secure elements.
10 • 52
Documentation v0.7
Starter public key
1.Starter Hello
Decryption OK ?
Public Key Verified ?
Version compatible ?
Starter Public Key
Protocol Version
Responder public key
No
STOP
Symmetric key
Yes
STOP
No
2. First Half Key
Decryption OK ?
Half Symmetric Key
Yes
3. Half Key and Responder Integrity
Integrity OK ?
Half Symmetric Key
Responder Integrity Hash
No
STOP
Yes
STOP
No
4. Starter Integrity
Integrity OK ?
Starter Integrity Hash
Yes
5. Handshake
finished
Handshake logic
There are three main functions that the Handshake has to accomplish:
3.2.1.
Client Hello
The client hello is the first message that starts the communication between the two clients. It
should announce the protocol version used and the Starter identity with its public key. As
explained in chapter 3.1 that means exchanging the protocol version numbers in order to verify
that the major version numbers are the same.
3.2.2.
AES key generation
In order to get the best possible entropy for the random number generator on which a good key
should always be based two different sources are relied upon.
Both participants are in charge to generate half of the key and IV, that way even if one of them
has a weak random number generator the other on will be able to compensate.
11 • 52
Documentation v0.7
Starter
Responder
256 random Bits
256 random Bits
128 bits Key
128 bits IV
128 bits Key
256 bit Key
128 bits IV
256 bit IV
AES 256 bit Symmetric Key and IV
3.2.3.
Public key exchange and authentication
Once we know the communication is based on compatible protocol versions we can continue to
the authentication phase. Since the concept of identity on the internet is kind of tricky we base
our authentication on a simple encryption test. Each the starter and the responder normally
know the public key of the other one But only the real original generator of a public key should
be able to decrypt it’s content. Based on this realisation both send each other one half of a
symmetric key which they encoded first with each other’s public key. So in order to be able
communicate each participant has to be authentic. If one isn’t the integrity check fails and the
connection is dropped (Authentication Failed).
Starters half of
symmetric key
Responders half of
symmetric key
Encrypted and decrypted with
respectif Private and Public keys
Whole symetric key
Whole symetric key
A successful decryption and verification of both integrity hashes by both clients is a proof of
identity validity for both clients.
FINISH
Wrong Hash
Decrypt Hash with
symmetric key
And compare
Right Hash
Integrity Hash
12 • 52
A successful decryption and verification of both integrity hashes by both clients is a proof of
Documentation v0.7
identity validity for both clients.
FINISH
Wrong Hash
Decrypt Hash with
symmetric key
And compare
Integrity Hash
Right Hash
Integrity verified and
Identity confirmed
Symmetric Key exchange and Identity authentication
3.2.4.
Handshake failure
There can be different reasons for a Handshake to fail. They can be of technical nature but also
be the result of attacks or incompatibilities.
Where
What
Why
Always
Wrong packet format
Impossible to decrypt
Unknown
Bad public key used
Starter Hello
Unknown contact public key
Incompatible versions
Contact not registered
Incompatible versions
symmetric key exchange
Bad integrity Hash
Corrupted packets
Handshake finished
Bad symmetric key
Bad assembly of key halves
Since all reasons to drop a Handshake can be caused by a Hacker or other malicious third party
a ban time is applied each time a handshake fails. In order to avoid attacks like DDoS (Denial of
Service) each time an IP fails a Handshake the ban time is doubled.
13 • 52
Incoming connexion
Handshake
Banned IP ?
Documentation v0.7
Handshake Finished
Ban List
IP allready
banned ?
No
Ban IP for 1s
IP
Yes
Double ban time
Handshake Failed
ban time
Every time a connexion is dropped the handshake emits an Error.
UndefinedError
Any error that isn’t detected correctly
BadPrivateKey
The private Key is corrupted or invalid
BadContactKey
The Public Key of the contact is corrupted or invalid
BadSymmetricKey
The symmetric key is corrupted or invalid
BadSecurityLevel
An unknown or invalid security level has been specified
IncompatibleProtocolVersions
The protocol versions aren’t compatible
IdentityCheckFailed
The contacts Identity failed to be verified for some reason
IntegrityCheckFailed
The integrity of the handshake is compromised
DataCorrupted
Data can’t be read correctly for some reason
Timeout
Waited too long for an expected answer
14 • 52
3.3.
Documentation v0.7
Packets
In order to easily parse specific information from the data stream, the data are split in chunks of
variable size. These chunks are called payload, they are the piece of data that the packet is
carrying.
In addition to the payload, a header is added to the packet. It contains information that allows
the data to be authenticated, reassembled, and routed to their proper destination.
3.3.1.
Handshake
During the Handshake, four different packets are exchanged between the two handshaking
clients.
The Starter is the client starting the handshake, and the Responder is the one answering the
handshake request.
The packets are exchanged in the following order:
1. Starter Hello (Starter)
32 bits (clear-text)
32 bits (rsa encrypted)
(variable) (rsa
encrypted)
8bits (rsa encrypted)
Packet size
Starter public key size
Starter public key
Protocol Version
2. First Half Key (Responder)
256 bits (rsa encrypted)
Packet size
First Half of the symmetric key + IV
3. Half Key and Responder Integrity (Starter)
256 bits (rsa
encrypted)
256 bits (gcm
encrypted)
Rsa encrypted zone
size
Second half of the
symmetric key + IV
Gcm zone encrypted
size
Responder integrity
hash
4. Starter Integrity (Responder)
256 bits (gcm encrypted)
Packet size
Starter integrity hash
5. Handshake finished (Starter)
8 bits (gcm encrypted)
15 • 52
packet size
Documentation v0.7
Handshake finished (0x10)
When the handshake fails, another packet is sended. It contains the State byte which is always
set to Undefined Error (0x00) as other error types are not suppose to be transmitted to the other
client. A ban time (in seconds) is added to inform the client when a retry will be allowed.
Handshake Failed
8 bits (clear-text)
Packet size
Handshake failed (undefined error)
Ban time (seconds)
3.3.2.
Generic packet
Once the Handshake is finished, every packet being transmitted between Apps uses the same
template.
Global packet
unsigned integer 64 bits
unsigned integer 32 bits
byte array (variable size)
Sequence Number
Encrypted payload size
Encrypted payload
AppUID (24 bits)
unsigned integer (32 bits)
byte array (variable size)
Destination App UID
App Payload size
App Payload
Encrypted payload
Note: see 3.5.1 for AppUID structure
3.4.
Encryption
Content encryption is defined to be used in the protocol in order to secure the communications
between the clients.
The encryption methods and the key length used must be considered as secure for the next 20
years at the moment of the implementations. This means that no existing computing system
should be able to crack the encrypted packet without at least 20 years of computations.
The target end point of the communication must be the only one to be able to decrypt the
communication. No third-party should be ever trusted regarding cryptographic materials
security.
Every user is responsible for the confidentiality and the storage of his keys.
16 • 52
3.4.1.
Documentation v0.7
Hybrid Cryptography
There are two main categories of cryptosystems:
●
Asymmetric cryptosystems
In this cryptosystem type, a different key is used to encrypt and decrypt the data.
The recipient of the data generates a private key which would be used to decrypt the
data, and a public key which can only be used to encrypt them. The private and the
public key are mathematically related, the private key being a hidden backdoor in the
encryption scheme.
This backdoor is really difficult to find for a computer, to find it has to resolve a discrete
logarithm problem (factorisation of a huge integer in prime factors). This process takes
so long on actual technologies that it is considered as impossible solve (approx. 6.4x1012
years for a 2048 bits RSA key for a regular computer1).
The only real threat towards this type of cryptosystem are flawed implementations such
as predictable key generation algorithms or padding scheme, and quantum computing
which do have really efficient algorithms to solve discrete logarithm problems (Shor’s
algorithm).
Practical example: Bob wants to send encrypted data to Alice.
Alice
Public Key
Data
Private
Key
Bob
Data
Encrypted Data
1. Alice generates her private key and its corresponding public key.
2. She sends her public key to Bob. She can do it without much precautions as she is
the only one that has the corresponding private key to decrypt the data anyway.
3. Bob encrypts the data and send them to Alice.
4. Alice use its private key to recover the plaintext data.
1
Source: Practical Cryptography - Ferguson & Schneier
17 • 52
Documentation v0.7
Remarque: Bob must be sure that the issuer of the public key he receives is Alice,
otherwise he cannot be certain that only Alice will be able to decipher the encrypted
data.
Due to the length of the key used and the complexity of their generation process,
asymmetric cryptosystems implementations are generally slow to operate (typically 85
Mib/s on an Intel Core 2 1.83 GHz2).
Asymmetric cryptosystems based on elliptic curves rather than on discrete logarithm are
far more efficient as they are secure with much smaller key length. But as they are more
recent they are more likely to contain undiscovered flaws.
●
Symmetric cryptosystems
In a symmetric cryptosystem, the same key is used to encrypt and decrypt the data. This
key must remain private and should be exchanged through a secure channel in order to
be used. Anyone in possession of the key can encrypt and decrypt data.
The key generation process has only one condition to be safe, it must be unpredictable.
Practical example: Alice wants to send encrypted data to Bob:
Data
Bob
Key
Key
Alice
Encrypted Data
Data
1. The key is exchanged through a secure channel (not shown here)
2. Alice encrypts the data using the shared key and sends it to Bob
3. Bob decrypt the message using the shared key to recover the plaintext data
This type of cryptosystem as they do not have structural backdoors generally do not
require key length over 256 bits, making their implementation fast and efficient.
2
http://www.cryptopp.com/benchmarks.html
18 • 52
●
Documentation v0.7
Hybrid Cryptosystems
The idea of a hybrid cryptosystem is to take the best of asymmetric and symmetric
cryptosystems and put them together.
Symmetric ones are fast and efficient which make them good for the processing of big
amount of data, but they require their key to be exchanged through a secure channel
before any processing.
This symmetric key can be encrypted with an asymmetric cryptosystem, making it
theoretically impossible to intercept and safe to exchange through an insecure channel.
As a small amount of data will be exchanged with this method, there is no performance
bottleneck.
3.4.2.
RSA
The RSA Cryptosystem is the most widespread asymmetric cryptographic method in use
nowadays. It has been developed by Ron Rivest, Adi Shamir, Leonard Adleman and first
published in 1977. It has been progressively adopted to secure most of encrypted data
transmissions.
Its asymmetry is based on the practical difficulty for computers to factor a large integer into
prime factors.
This chapter aim to provide a quick overview of the internal process behind this method.
Key pair generation algorithm:
1. Choosing two distinct random prime number 𝑝 and 𝑞
𝑝 = 𝑟𝑎𝑛𝑑𝑜𝑚 𝑝𝑟𝑖𝑚𝑒 𝑛𝑢𝑚𝑏𝑒𝑟
𝑞 = 𝑟𝑎𝑛𝑑𝑜𝑚 𝑝𝑟𝑖𝑚𝑒 𝑛𝑢𝑚𝑏𝑒𝑟
2. Computing the modulus 𝑛
𝑛 = 𝑝. 𝑞
3. Compute the Euler’s totient function 𝜑(𝑛)
𝜑(𝑛) = (𝑝 − 1) × (𝑞 − 1)
4. Choosing a random public exponent 𝑒 greater than and coprime with 𝜑(𝑛)
𝑒 𝑤𝑖𝑡ℎ 𝑒 ∈ ℕ, 𝑒 < 𝜑(𝑛), 𝑎𝑛𝑑 𝑔𝑐𝑑(𝑒, 𝜑(𝑛)) = 1
5. Computing the private exponent 𝑑
𝑑 ≡ 𝑒 − 1 𝑚𝑜𝑑 𝜑(𝑛) ⇔ 𝑑. 𝑒 = 1 𝑚𝑜𝑑 𝜑(𝑛)
6. Exporting ready to use key pair
Public key: (𝑛, 𝑒)
Modulus and public exponent
Private Key: (𝑛, 𝑑) Modulus and private exponent
19 • 52
Documentation v0.7
Encryption and Decryption algorithms are pretty straight forward mathematical expressions.
They are optimized for computers through various sub-algorithms such as the square-andmultiply algorithm and the Chinese remainder theorem.
Encryption:
𝐶 ≡ 𝑀𝑒 𝑚𝑜𝑑(𝑛) ⇔ 𝐶 = 𝑀𝑒 𝑚𝑜𝑑(𝑛)
With 𝐶 = 𝑐𝑖𝑝ℎ𝑒𝑟𝑡𝑒𝑥𝑡 and 𝑀 = 𝑐𝑙𝑒𝑎𝑟𝑡𝑒𝑥𝑡
Decryption:
𝑀 ≡ 𝐶𝑑 𝑚𝑜𝑑(𝑛) ⇔ 𝑀 = 𝐶𝑑 𝑚𝑜𝑑(𝑛)
With 𝐶 = 𝑐𝑖𝑝ℎ𝑒𝑟𝑡𝑒𝑥𝑡 and 𝑀 = 𝑐𝑙𝑒𝑎𝑟𝑡𝑒𝑥𝑡
More information can be found on the Wikipedia page of the RSA cryptosystem3.
Elliptic curve based cryptosystems are much more efficient than RSA in term of key size vs.
security ratio. This means they are secure with much smaller keys, thus requiring less
computational power and less energy to generate keys and process data.
But since they are more recent, they have not been as well-tested as RSA and the probability
that they might contain structural flaws is greater.
Furthermore, recent publications of leaked NSA internal documents suggest that the NSA might
have the NIST standardized a flawed a pseudo-random number generator that is based on
Elliptic Curve (Dual EC DRBG4).
After the publication by the New York Time5, the NIST promptly removed the algorithm from the
standard and issued an official recommendation6 to avoid this random number generator.
Since the main goal of this protocol being security, it cannot rely on a possibly flawed
cryptosystem. Thus this protocol is using RSA.
Known attacks:
● Brute force
● Side channel
● Schor’s/Grover’s algorithms
3
http://en.wikipedia.org/wiki/RSA_(cryptosystem)
http://en.wikipedia.org/wiki/Dual_EC_DRBG
5
http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html
6
http://www.nist.gov/itl/csd/sp800-90-042114.cfm
4
20 • 52
3.4.3.
Documentation v0.7
Advanced Encryption Standard (AES)
The Advanced Encryption Standard otherwise known as the Rijndael cryptographic algorithm is
nowadays (in 2014) the reference symmetric cryptographic method. It is used by many
communications protocol like TLS, SFTP, or SSH, and secret services around the world to
provide strong data encryption.
The algorithm has been built to run fast on computers while being safe to brute-force attacks.
Some mainstream processors from the manufacturer Intel and AMD are providing hardware
acceleration for AES encryption/decryption with the AES-NI instruction set, accelerating the
process from 3 to 10 times compared to a similar processor operating without AES-NI7.
Plain text
AES
Cipher text
Symmetric
Key
Plain text
AES
Cipher text
Symmetric cipher basic flowchart
As a symmetric cryptosystem, it uses the same key to encrypt and decrypt the data.
It processes the data in 128 bits block and the keys can be 128 bits, 192 bits, or 256 bits long.
The NSA established AES with 256 bits key as their standard for top secret document
encryption.
7
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
21 • 52
Documentation v0.7
Key Expansion
Add Round Key
Substitute Bytes
Shift Rows
Mix Columns
Substitute Bytes
Shift Rows
Add Round Key
Add Round Key
Output result
AES Flowchart
The AES algorithm use different types of rounds and different round number depending on the
key length:
128 bits key -> 10 rounds
Every operation is done on a 4x4 matrix containing the 128 bits data block to process.
Before the first the key is expanded in sub-keys, one for each rounds.
The first round add the first round key to the block (bit-to-bit XOR operation).
For the next rounds except the last one, multiple operations are done on the block:
→ Sub Bytes: The bytes are substituted according to a fixed lookup table.
→ Shift Row: The rows of the matrix are left-shifted, from one cell for the first one, two for
the second, and so on to the fourth row.
22 • 52
Documentation v0.7
→ MixColumns: Every column of the matrix is mixed by multiplying it to a fixed matrix.
→ AddRoundKey: The round key is finally added to the matrix using a bit-to-bit XOR
operation on the matrix.
The last round is the same except that the MixColumns operation is omitted.
Known attacks:
● Brute force
● Join in the middle8
● Side channel
3.4.4.
Galois/Counter Mode (GCM)
The Galois/Counter Mode (GCM) is a mode of operation for symmetric key cryptographic block
ciphers.
It provides integrity check upon encryption by attaching a Galois Message Authentication Code
(GMAC) hash to the encrypted message. This hash authenticates the clear text message,
making both the encrypted message and the hash are impossible to change without being
noticed by the recipient.
This GMAC is calculated by a GHASH function. It uses a Galois field of 2128 to combine to
counters to produce the hash.
The GHASH function is defined as following:
GHASH(H,A,C) = Xm + n + 1
Where 𝐻 is the Hash Key, a string of 128 zero bits encrypted using the block cipher, 𝐴 is data
which is only authenticated (not encrypted), 𝐶 is the ciphertext, 𝑚 is the number of 128 bit
blocks in 𝐴, 𝑛 is the number of 128 bit blocks in 𝐶 (the final blocks of 𝐴and 𝐶need not be exactly
128 bits).
The 𝑋𝑖 variable is defined as following:
8
http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf
23 • 52
Documentation v0.7
Where 𝑣 is the bit length of the final block of 𝐴, 𝑢 is the bit length of the final block of 𝐶, and
||denotes concatenation of bit strings. Note that this is an iterative algorithm: each 𝑋𝑖 depends
on 𝑋𝑖−1 , and only the final 𝑋𝑖 is retained as output.
GCM data flowchart
24 • 52
Documentation v0.7
The GCM mode is mostly used with AES encryption, making it very fast on most processor as it
also uses some AES-NI instructions (PCLMULQDQ). It also provide a way to authenticate
additional unencrypted data (multi-channel authentication).
GCM-AES It is used by the most recent protocols like TLS 1.2, IPSEC, or SSH. It is also
included in the NSA Suite B Cryptography.
Known Attack:
● Collisions
● Side channel
● IV nonce reuse
3.4.5.
Protocol specific GCM/AES IV generation
Since the encrypted packets must be transmitted through multiples protocols where the integrity
and the order of arrival from the sequences is not always guaranteed, the GCM encryption must
be re-initialized for each sequence. This ensure the packets to be independent from each other
and allow the encryption to recover from a lost or corrupted sequence.
A new Packet Initialisation Vector must be generated from the Base Initialisation Vector that has
been exchanged during the handshake.
To provide strong encryption, the Packet Initialisation Vector must be unique.
The Base IV must remain unique for each session and should not be changed during the
session as it is used to generate the other Initialisation Vectors.
3.4.5.1.
Handshake
During the handshake, after the Key and the Base IV have been generated and exchanged, all
the fields to be encrypted are processed with a Packet IV.
The Packet IV is generated by copying the Base IV adding an offset its last byte.
This offset start at 0 and is incremented for each encryption/decryption operation.An overflow of
the last byte’s value is not a problem and thus is permitted.
25 • 52
Base IV
Documentation v0.7
Last Byte
IV Offset
(starts at 0)
Packet IV
Last Byte
Handshake Packet IV generation
3.4.5.2.
Global data transmission
Once the handshake is finished, the Packet IV is generated in a more robust way.
Each packet (other than handshake) has a sequence number. This number is used to generate
the Packet IV, thus allowing the decryption to be properly initialised for any incoming packets.
The Packet IV is generated by concatenating the Key, the Base IV, and the Sequence Number,
and by hashing the result with the SHA 256 algorithm. This provide a unique and private Packet
IV which is easily retrievable for the participants of the session. Contrariwise it is practically
impossible for anyone not in possession of the Key and the Base IV to retrieve it only with the
sequence number.
Since the Key and Base IV are unique for a session and the sequence number is unique for a
session, the resulting Packet IV is globally unique, and the chances of collisions of the hash are
negligible.
26 • 52
Key
Base IV
Documentation v0.7
Sequence number
SHA 256
Packet IV
Global Packet IV generation
3.5.
Apps
To build a flexible and future-proof and multiple-channel communication, the protocol introduces
the notion of apps. They are higher level components meant to be used directly by the end-user.
They should provide a graphical user interface and process the higher level data.
On the protocol side, they are connected to the core protocol the with a single pair of methods
to send and receive data. The protocol provides a way to route the incoming data to the proper
App. The routing and the registration of routes is provided by the internal App Manager.
3.5.1.
App Manager
The App Manager is the component that provides the route registration and the identification of
a single App started in a client.
Every App that is started has a Unique IDentifier (UID).
This UID is composed of two elements:
● App Type Identifier: a 8 bits unsigned integer identifier that identify the type of the App.
● Instance Number: a 16 bits unsigned integer identifier that is incremented every time an
App of the same type is started and registered in the client.
8 bits unsigned integer
App Type Identifier
Instance Number
App UID structure
An App UID must be unique in a client registers, otherwise it will not be able to route the
incoming packets to their proper destination. Having the same UID for two communicating Apps
in two different clients is not a problem.
Anatomy of a packet of the App Manager:
27 • 52
Documentation v0.7
24 bits UID
24 bits UID
Instruction
Local App UID
Distant App UID
List of the instructions:
ID
Name
Description
0x00 Start App Request
A request to start an App to respond to an app started by
another client. Since only the distant App UID is needed, the
local App UID is left undefined (App Type = Undefined (0xFF)).
0x01 App Started Signal
A signal emitted by the client when it has started an App
following a Start App Request. It contains the UID of the started
local App and the UID of the App that emitted the request. These
two UIDs are a route record, they must be registered by both
App Managers.
0x02 App Closed Signal
A signal emitted by an App Manager to unregister and eventually
close an App.
3.5.2.
App Type Identifiers
Some of the App Type Identifiers are reserved for routing purpose or for the default apps. The
others are dynamic and are free to be used by custom App implementation.
AppType Name
unsigned integer IDs
AppManager
0x00
Messenger
0x01
VoIP
0x02
VideoStreamer
0x03
DataTransfer
0x04
(dynamic types)
(0x05 - 0xFE)
Undefined
0xFF
28 • 52
3.6.
Documentation v0.7
Links
In order to effectively exchange data between the clients there has to be a well-adapted
communication protocol in use. Most communications nowadays rely on simple TCP/IP. Since
some applications don’t really have a need for high quality transmission and would rather have
a faster data stream it might also be interesting to allow the use of UDP.
Also we may need to have more specifically tailored protocols for intensive usages like VoIP or
video streaming and that would be RTP.
3.6.1.
TCP: Transmission Control Protocol
The transmission control Protocol is a network Protocol which defines the
conventions about the way data has to be exchanged between devices.
It provides a data flow in two directions which is both ordered and error-checked.
Today TCP is broadly considered as one of the more reliable protocols and is
widely used on the web.
3.6.2.
UDP: User Datagram Protocol
The user datagram Protocol in opposition to TCP only goes in one Direction and
doesn’t necessarily have to be ordered. Also error-checking is possible is isn’t as
reliable as TCP and since most of the time UDP is used for it’s speed and not it’s
quality there is no real need for it.
3.6.3.
RTP: Real-Time transfer protocol
The real-time transfer protocol could be considered as a hybrid protocol
consisting of a UDP having the advantages of a TCP while keeping most of his
own.
It is mainly used to stream voice and/or video data and allows this to work fast
while keeping the lost data to a minimum.
29 • 52
4.
Documentation v0.7
Client Implementation
4.1.
Structure
The Prototypes Structure is based on one main control class called SVoIP which is in charge of
effective instantiating and connecting the different Classes.
SVoIP
uPnP
list of apps
list of network managers
Listener
connects the apps to the packet agents
listener port
search for local devices and upnp
enabled routers
if possible configures port forwarding
NetworkManager (one per contact)
App
UI
do things with the user, communicate
with one or more network managers
through svoip
Contact
list of links
list of apps associated
routing table (apps/links)
Parse, assemble, encypt and decrypt
packets.
Messenger
VoIP
Hanshaker(one per contact)
Contact
Private/Public Key
Trys all known IP and authenticates itself
Uses the Public and private Keys.
Generates the AES session key.
Verifies the handshake integrity.
returns connected Socket for
NetworkManager creation
Link (max one per type)
VideoStreamer
DataTransfert
Socket
socket wrapper to send and recieve raw
encrypted packet
TCP
UDP
RTP
SVoIP: in order to be operational SVoIP starts the UPnP module and displays a User Interface.
Once done it starts the Handshakers and waits for user interactions or network returns.
UPnP: the UPnP Module will try for a definite time to find an enabled router and to configure
port forwarding for the designated port. If he does not find a router or the configuration doesn’t
work he simply stops.
Handshaker: There is one Handshaker per Contact Periodically he will try to connect to one of
the contacts known IPs and if successful initiate a Handshake. If successful he will return the
Socket and SVoIP will start a NetworkManager.
NetworkManager: Once the Handshake was successful the network Manager starts and
manages the apps which will eventually be started by one of the clients. He will also start new
30 • 52
Documentation v0.7
Links if needed and route all the incoming data from the Links to the appropriate apps after
assembling and decrypting it.
App: Apps are either started in reaction off the User clicking a button or one of the connected
clients request. An app is connected to one or more NetworkManager and can ask to use
specific Link Types. Once an app is started it should be able to send and to receive data from
his Contact(s).
4.2.
User Interface
To develop the user interface of the prototype, some brainstorming was required in order to
define the functionality and design guidelines.
As a result the following point where retained:
━ Simple: the interface has to hide most of the program complexity and goes for user
everyday concern first.
━ Touch-friendly: in order to be fully cross-platform, it should behave well and be intuitive
on touchscreens as well as mouse interactions.
━ Size-responsive: to achieve multi-device portability and homogeneity, the interface
should be able to be scaled from 4 inches smartphones to 32 inches wide computer
screen. It should use the same unified design and the same interactions to ease the user
transition from one to another.
━ Modern-looking: inspired by the web and software flat-design trend, the UI of the client
should adopts bold colors, flat surfaces, explicit visual content, and minimalistic layout. It
keeps the interface simple and easy to use for anyone.
Along experimenting on the prototype itself, a few concepts were made using these guidelines.
The following views had to be carefully thought in order be as intuitive as possible:
─ Contact View: a view containing all the contacts in store.
● The contact status
► Add/Edit/Delete a contact
► Start an App with a contact
─ VoIP View: a view for both voice and video communication
● Both images from the video communication
► Call/End call
► Set Volume/Mute sound output
► Mute microphone
► Enable/Disable video
─ Instant Messenger View : a view containing a text conversation
● The messages of the partner in communication
► Type messages
► Send messages
► Send a file
─ Settings View : a view to interact with the settings of the program
● Password options
31 • 52
●
●
►
►
►
►
►
►
Documentation v0.7
Network options
RSA Public/Private Key
Change password
Display/Hide typed password
Change main listen port
Generate Private Key
Import/Export Public and Private Key
Save or Cancel modifications
(● View, ► Control)
As a result of this study a first concept was made:
First UI concept
It has controls to add contact, go to the settings, and displays the contact in a grid of rounded
photos with an indicator of their status and their name under it. The images are turning black
and white when a contact goes offline.
A click (or a touch) on one of them brings three icon buttons to start VoIP, Instant Messenger, or
bring a menu with further options such as edit the contact, delete it, or start a third-party App
with it.
Even if it matched most of our design guidelines, this concept with this grid of round icons had a
few quirks. It was a bit way of the design people are used to have on similar programs making it
confusing to use, and the big photos makes it layout expansive, representing only a few contact
on small screens and allowing only small name to be displayed.
32 • 52
Documentation v0.7
So a second concept was made, more in the classic flat-design trend, inspired by the design of
Google’s Android and Microsoft’s Modern UI. This concept takes different approach to the
problem by starting the design from the smaller screen and extending it to the biggest.
Smartphone interface:
List of contact
Interaction on a contact
Instant Messenger
Tablet interface:
Instant Messenger
33 • 52
Documentation v0.7
Computer interface:
Voice and Video communication (and contact interaction)
This concept meets all the requirements and brings an intuitive, multi-screen optimized, and
good looking design to the final user.
Some design elements have been kept from the first concept like the letter indexed scroller of
the contact list. But most of it comes from the experimentations on the prototype.
The actual prototype design is at the moment of the thesis project end still lacking behind the
concept due to technical and time constraints. It is functional on touch screens and work well on
a computer screen but has not been optimized for the smaller devices and their system design.
However the implementation tool used to build it are fully compatible with mobile platform and
the design from the second concept is a reasonably achievable goal to reach using the same
tools.
34 • 52
Initial configuration wizard
Contact list
Password input
Documentation v0.7
Password error
Instant Messenger App
35 • 52
Documentation v0.7
Video App
Password settings
VoIP App
Network settings
36 • 52
RSA Settings
Documentation v0.7
Contact add or modify
The prototype has been optimized for high pixel-density (hdpi) touch-screens and had the
opportunity to be tested on such device.
An icon set has been drawn from scratch for the prototype, which has been massively reused
for the second concept design.
Prototype icon set
This icons have a distinctive shape using simple and meaningful symbols to represent their
functions and have a specific colour scheme that allow them to be distinguished at first sight.
37 • 52
4.3.
Documentation v0.7
Contacts
A contact is a locally stored set of information regarding another person known by the user.
This set is composed of the following data:
● ID: a unique identifier used locally to retrieve and interact with the contact records.
● Name: a user friendly name aimed for easy contact recognition by the user. Since an
unique contact ID exists, this name can be changed and duplicated name are allowed.
● IP List: a list of IP addresses that is used to reach the other client. Each IP is tested
continuously. Should one respond, a handshake is tried.
● Port: the network listening port of the other client.
● Public Key: the public key of the contact that allow the communication to be encrypted.
The contact information are private and thus should never be exchanged through an unsecure
channel. Passing them through regular unencrypted internet communication could lead in the
swapping of the public key with a foreign one, allowing a man-in-the-middle attack to be
performed. The safest way to pass the contact information to another person is to do it offline,
on an usb stick, a QR Code, or written on paper.
A way to authentify the online contact information and retrieve them by solely using the Public
Key is to be provided by further versions of the protocol.
The contact are stored in a SQLite3 database that is driven by Qt’s SQL module. The integrity of
the table is verified by a hash of its content that is stored in another table of the same database.
4.4.
App Manager
The App Manager is the component which provides mechanisms to retrieve the destination App
to pass the data to. It is also responsible for ensuring that the other partner has the same App,
in a compatible version, to ensure that the communication to be properly established at both
ends of the protocol. A different App Manager is started for each Contact, the Client wants to
communicate with.
Let’s define a few keywords for the App Manager:
₋ User: the user starting an App.
₋ Partner : a distant client responding to the requests of the App Manager
₋ App Unique Identifier (UID) : a unique number identifying the app in the client. It is
composed by two fields, an App Type and an Instance Number.
₋ Local App Table: a table containing the Apps started on this client and register to this
App Manager.
₋ Routing Table: a table containing a distant UID for each App registered in the Local App
Table.
₋ Start App Request: a request to the Partner to start an App to respond to the User. It
contains the UID of the User’s App to respond to.
38 • 52
₋
₋
Documentation v0.7
App Started Signal: a signal emitted by the Partner App Manager when it has started an
App following a Start App Request. It contains the UID of the App started and the UID of
the App that emitted the request. These two UIDs are a route record.
App Closed Signal: a signal emitted by an App Manager to unregister and eventually
close an App.
When a user wish to start an app, the following steps are done to start the App at both ends and
register the route between them:
1. The User start the app, an App Unique Identifier (UID) composed by a App Type and an
Instance Number is generated by incrementing the Instance Number for the defined App
Type. The UID must be unique for a client, but can be the same for two different clients.
2. The UID is registered by the App Manager in his Local App Table containing all the Apps
started for a Contact and the App Manager of the User issue a request to the App
Manager of the Partner.
3. The Partner’s App Manager Start the corresponding App, give it a UID and register it in
his Local App Table. Then it registers it in his Routing Table and sends back the UID
pair representing the route to the User’s App Manager.
4. The User’s App Manager registers the route in his Routing Table and the communication
between the Apps can start.
User starts App
Generate UID and
Register to Local
App Table
Send Start App
Request
Start App with the
same App Type
Register UID pair to
Routing Table
Generate UID and
Register to Local
App Table
Register UID pair to
Routing Table
Send App Started
Signal
App registration flowchart
39 • 52
4.5.
Documentation v0.7
Apps
4.5.1.
Messenger
The Messenger App is an instant messaging tool that displays text conversation and allow users
to chat together. It is composed of a list of all the exchanged messages that form the
conversation and an input field to type new messages. Sent messages are displayed on the
right and incoming ones on the left. Every Contact’s messages are identifiable by a specific text
colour. Rich text formatting is available using html marking syntax, enabling the user to
emphasize certain messages or send link to web pages.
Example:
Will be displayed as:
<h1><i><font color=”red”>Hello Bob !</font></i></h1>
Hello Bob !
The message is sent when the user presses the “Return” key after typing it in the dedicated text
input.
Return
pressed
Get Text from GUI
Display written
messages on the
right side
Add to html
local
ToByteArray
message-list
Display incoming
messages on the
left side
Add to html
incoming
message-list
Tohtml
Send Data
Receive Data
Messenger App data flow
40 • 52
4.5.2.
Documentation v0.7
Voice over IP
The Voice over IP App (commonly known as VoIP) is the App allowing voice to be transmitted in
in full-duplex and in real-time between two clients.
The sound has to be very efficiently compressed with a minimal delay to keep the protocol
latency as low as possible.
To achieve this, the Opus Interactive Audio Codec in combination with the Real-Time Protocol
(RTP) were chosen for their efficiency and the fact that they were open-source and platformindependent.
The Opus codec has been originally developed as a hybrid codec based on the work of Skype
on the CELT codec and Xiph.org on the SILK codec to provide a general purpose sound codec,
optimized for real-time purpose. However, at equivalent quality it has been proved to be more
efficient than the MP3 codec for fullband use and the G.722 codec for Telephony over IP. It
allows encoding frame size ranging from 2.5 ms to 60 ms, variable bitrate from 6 kb/s to 510
kb/s, and sampling rates from 8 kHz (narrowband) to 48 kHz (fullband) making it flexible and
efficient for real-time applications. Last but not least it provides an optimized profile for speech
encoding.
Comparison of sound codec (source: Wikipedia)
This codec open-source and standardized by the IETF under the RFC 6716. A portable C89 API
is available on the official website9 in version 1.1.
9
http://www.opus-codec.org/
41 • 52
Documentation v0.7
It is already supported as a part of the WebRTC protocol by Mozilla Firefox and Google
Chrome, and by other VoIP clients such as csisimple, Teamspeak, and Mumble.
Other programs for also use it for high definition audio streaming purpose (VLC, SteamOS,
IceCast, …).
The Real-Time Protocol is also a standard from the IETF (RFC 1889). It is based on the UDP
protocol for lightweight one way communication, but allow the receivers of the stream to send
periodical reports to the streamer on the link capacity.
It is used as underlayer for a vast amount of streaming protocols including most of the Voice
and Video over IP protocols.
The library used by the prototype to provide RTP support is JRtpLib, an open source C++
implementation that work on windows and linux-based systems. The latest version is 3.9.1 since
November 201110. It fully supports the RTP specifications as defined in the RFC. It is opensource and free to use.
The voice is encoded, transmitted, and rendered as following:
Voice PCM
acquisition
OPUS speech
compression
Send Data
PCM sound
output
OPUS speech
decompression
Receive Data
Voice App data flow
The pcm acquisition and rendering are done by the low-level multimedia component of the Qt
framework.
10
http://research.edm.uhasselt.be/jori/page/index.php?n=CS.Jrtplib
42 • 52
4.5.3.
Documentation v0.7
Video over IP
The Video App is used to transmit full-duplex video stream, allowing the user to see each other
while talking together.. Since the quality and latency are as important to provide a good user
experience, the used codec should be picked with care in order to provide the best video quality
with the smallest possible bandwidth usage.
For that purpose the vp8 codec has been chosen which is a royalty-free alternative to the
popular H.264 codec. It was originally developed by On2 before being bought by Google and
added to the WebM standard.
The app in itself is pretty simple and works as follows:
Camera
The right canvas
displays raw
camera data
Display
Encode
Send Data
The left canvas
displays
decoded frames
Display
Decode
Receive Data
Video App data flow
4.6.
Links
The Links are an abstraction that represent a connection between two clients. Similar to the
sockets, they are generally wrapping around a socket object and provide simple interface to be
used by the NetworkManagers.
There are currently three types which share a common interface but have different
characteristics.
43 • 52
4.6.1.
Documentation v0.7
Structure
The TCP-Link is the standard Link of every Contact. It is the first link a Network
Manager opens and it stays open as long as both contact are reachable.
The other Link types work the same way but are not necessarily used.
Link structure
TCP
(Socket, Contact)
UDP/RTP
(IP,port, Contact)
The socket is passed after a
successful handshake
The socket is opened
on request
NetworkManager
outgoing
Writes Data on the Socket
NetworkManager
incoming
Reads Data from the Socket
On request the Link can return specific
information about his status and his Contact.
Status : ONLINE, OFFLINE, ERROR
Host : returns IP and port or Contact
4.6.2.
Type ID’s
Since apps don’t start Links themselves a “LinkType” logic has been set up.
Every type has a code that allows the different objects to design easily which kind of Link is
needed.
Type
code
TCP
0x00
UDP
0x01
RTP
0x02
44 • 52
4.7.
Documentation v0.7
UPnP NAT Configuration
The Prototype will be working based on a client server logic which is really useful be poses on
major problem. The client can’t connect to the server if the latter is positioned behind a firewall
and/or NAT infrastructure. Technically talented Users can of course configure manually a port
forwarding in their router but most Users won’t be able to do that.
UPnP is a Protocol mainly used for media devices but also for automated network management.
It is notably possible to configure port forwarding on an UPnP enabled router just by sending
xml strings from inside the local network.
UPnP works very differently from one router to another and sometimes it might not work at all
but in the cases it does it can be of valuable help.
UPnP Device ?
Local server
Local Computer
UPnP Device ?
Try Configure Port
forwarding
YES
UPnP Device ?
UPnP Device ?
Router
Client
Wifi
UPnP Device ?
UPnP Device ?
Local Computer
Printer
45 • 52
Documentation v0.7
As soon as the program is launched it will start searching for an UPnP enabled router. It does
that by broadcasting an xml query on the local network. If there is an UPnP enabled device it
will answer and the client will attempt to configure Port Forwarding for his open port and IP.
4.8.
Local data storage
Some data need to be stored locally and cannot be shared for security reasons. In order to be
secure against Trojan and other malicious software that could copy or alter them, they should
be encrypted, authentified, and protected by a password.
There are two elements to secure:
● The contact database: a database with a table containing all the contact information, it is
a SQLite3 database in a file named “contacts.db3” processed by driver provided by Qt’s
SQL module.
● The keyring: the asymmetric private key that defines the user identity, it is stored in a
xml structured file named “keystore.dat”.
To encrypt everything a key and an initialization vector are needed. The key is generated from
the password using PKCS#5 algorithm with 1000 iterations to minimize the brute-force
weakness of the password.
The password is verified before a key is generated by a SHA 256 hash that is stored in clear in
a text file named “settings.ini”. The password itself is never stored. Furthermore, the hash is
salted with a unique salt to be safe again rainbow-table attacks. This salt is 128 bits long and is
generated on program first start and then stored in the same file as the hash (settings.ini).
The salt is used as Initialization Vector for the encryption.
The encryption scheme used is AES with a key length of 256 bits, but the mode differ:
● For the contact database, the Cipher feedback (CFB) mode is used as the database
already provides an integrity check.
● For the keyring, the Galois/Counter Mode(GCM) is used to provide both encryption and
authentication.
In both file decryption, the data are rejected if the integrity check fails.
46 • 52
Documentation v0.7
Password input
Salt
SHA 256
Password hash
Hash match ?
No
Wrong password
Yes
PKCS#5 (1000)
AES Key
IV
File decryption key generation
4.9.
Programing Tools
4.9.1.
Qt
Qt is a cross-platform application and UI framework for developers using C++.
It allows to write C++ programs with GUI’s and high level hardware access
without losing the possibility to compile on most mainstream machine.
Supported machines are for example: Windows, Windows RT, Mac Os X, Linux,
Android and iOS.
47 • 52
4.9.2.
Documentation v0.7
QtCreator
Qt Creator is the dedicated Platform for all Development with the Qt framework. It would of
course be possible to develop Qt code with any given IDE but Qt Creator is particularly
optimized for the task.
4.9.3.
Microsoft visual C++ 64 bits compiler
Since this project is coded on windows the msvc2012 compiler in it’s 64 bits version is used.
48 • 52
4.10.
Documentation v0.7
Libraries
To provide a rich set of functionalities, enhanced security, and to speed up the development
process, a few external library where used:
Crypto++: One of the most used and oldest (development started in 1996) C++ library for
cryptography (with OpenSSL). It is known for its top class performances and solid security. It is
platform independent but take advantages of low level instruction sets of the x86/amd64
architecture. Up to date, the last version (v5.6.2) was published on the 2/20/2013. It is opensource and free licenced under the Boost Software License 1.0.
Official website: http://www.cryptopp.com
Libopus: The reference c library for the Opus Interactive Audio Codec. While many wrapper for
many languages exists for this library, it is the only implementation available at the moment (in
version 1.1) of this newly standardized codec. This implementation is platform independent. It is
open-source and licensed under a three-clause BSD license.
Official website: http://www.opus-codec.org
Jrtplib: A good and simple to use C++ implementation of the RTP protocol created by Jori
Liesenborgs. It is compatible with Windows, Solaris, and GNU/Linux based systems. It is free to
use and licensed under a custom and very permissive copyright.
Official website: http://research.edm.uhasselt.be/jori/page/index.php?n=CS.Jrtplib
Libvpx: The official reference implementation for the VP8/9 video codec. Written in c, it is
designed to be cross-platform. With performance similar to its concurrent H.264/H.265 it has the
advantage to be open-source and freely licensed under a BSD-style license.
Official website: http://www.webmproject.org
49 • 52
4.11.
Documentation v0.7
License
The code is already open source, but since in the case of lack of license code cannot be used
or changed by any person it is imperative to add such a legal construct.
There are three points that are important.
- Everyone should be able to use this code
- Everyone should be able to change this code
- Everyone should be able to do with this code whatever he wants.
In order to accomplish this a License has been chosen which goes like this:
“Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.”
50 • 52
5.
Documentation v0.7
Conclusion
This project is great step in the right direction; making network communications safer for the
common man is a never ending enterprise that could only thrive in the future. By developing
decentralized protocols, we ensure the internet to remain independent and resilient. This
protocol however is just a little seed that still need to sprout, one among many other that offer
the same or similar functionalities. There is a real need for such a protocol to be broadly
available, and developer gather around the internet to improve it and code the citizen’s moral
rights in everyday protocols.
By opening this protocol to the open source community, we hope that it will be further developed
with or without us, and that compatible clients will be published.
This project was an amazing learning opportunity for us, as well as interesting teamwork
experience, dealing with everyday human and hierarchical issues is part of any project.
What project is ever finished? There is still so much to do, this is only a first functional draft of
the protocol, a 0.1 version that urges to evolve in order to become what it should be:
A broadly available general purpose protocol that secures anyone’s data, easily and
everywhere.
5.1.
Perspectives
Protocol
The Protocol clearly works but already let’s see where the issues are or are
about to be.
The performance may never be as good as with encrypted connexions but that
does not mean it is bad to try.
In any case there should be as many security reviews as possible before really
trusting this protocol. Until now reviews have always been followed by major
changes in the structure which means that they actually lost every meaning. A
useable application of this protocol should be reviewed thoroughly before
releasing it without making any changes during this process.
Prototype
One of the most important sides of the prototype is its structure. All the
performance is based on it all the traffic goes through it. It should, if the
prototype wants to ever pass into an Alpha or even Beta version be the best
optimized part in the whole program.
The GUI too, even if it does not impact much on the performance should be
rethought. It might well be one of the most important features since it is the only
one the user really is conscious of.
And of course it is never bad to add some new features in form of apps. Maybe
syncing a folder not unlike “dropbox” or maybe hosting a totally secure
website...
51 • 52
Documentation v0.7
Additional
Of course the whole project could evolve… it should really. Tracking down
contacts is with the actual system really bothersome. A decentralized and
reviewed PKI system and/or a dedicated technical solution to track down IP
addresses would be a real relief for the Users.
There could even be an idea of a Social network based on a secure Mesh
network of Connected Users.
And of course The protocol could and should be used for totally different case
scenarios. Maybe encrypting whole networks by using it on routers.
52 • 52
Appendixes
A. Tests
B. References
C. Contingency Plan
Appendix A: Tests
Appendix A: Tests
Part 1: Basic communication and Handshake
Test #
1
2
3
4
Description
Test protocol
Expected Result
TCP connection
and data
transmission test.
Using the prototype implementation and Qt’s
network objects, a TCP connection is established
and a test vector is transmitted.
The two prototype clients are running on
computer connected through a network. The
network connection functional.
A connection should be established and the
test vector should arrive to the client and the
received test vector should match the sent
one.
Ip ban protection
● An incoming connection is attempted while the
starter IP address is still banned.
The connection should be dropped almost
immediately after TCP handshake.
● A test vector is encrypted using a public key.
● The result is sent over a TCP Link to the other
client.
● The received packet is decrypted using the
corresponding private key.
The received test vectors should match the
sent one after decryption.
Starter:
● A 256 bits cryptographic secure pseudo random
number is generated.
● A copy of this number is encrypted using RSA
and sent to the other client.
● The local version is split into halves, and they
are saved as first part of the AES Key and IV.
Responder:
● The other client decrypt the incoming packet
with its private key.
● The resulting 256 bits number is split into
halves, and saved as first part of the AES Key
and IV.
The two clients should be able to
reassemble the same AES Key and IV and
have them available for further use.
RSA encryption /
decryption
AES key assembly
Result
Observations
SUCCESS
SUCCESS
Dropping the connection before TCP
handshake would be a better
protection against flooding.
SUCCESS
SUCCESS
1 • 10
Appendix A: Tests
The same process is repeated to generate and
exchange the second part of the Key and IV
except that the Responder generates the second
part locally and sends it to the starter.
5
6
7
8
GCM-AES
encryption /
decryption
● A test vector is encrypted by the first client using
the AES key and IV exchanged during the
handshake.
● The result is sent to a second client.
● The second client decrypt it with its copy of the
key and IV.
The received test vector should match the
sent one.
GCM-AES payload
alteration
● A random bit of the encrypted payload from the
test #5 is flipped before being sent.
● The second client tries to decrypt it.
10 consecutive trials are made.
The decryption should success but the
integrity check integrated in the GCM mode
should fail.
Integrity check
For this test, all the messages sent and received
by both clients during the handshake are added
to the integrity digest. The digests of both clients,
sent and received are then compared.
The integrity of the messages transmitted is
checked manually to ensure that the integrity
mechanism is the only part tested here.
The sent integrity digest of the first client
should be the same as the received integrity
digest from the second client.
Reciprocally, the sent integrity digest of the
second client should match the received
integrity digest of the first client.
Test cases:
- Bad Private Key: a bad private RSA key is
loaded into the decryptor.
- Bad Contact Key: a corrupted public key is
loaded into the RSA encryptor.
- Bad Symmetric Key: a symmetric key or IV of
length other than 256 bits is used.
- Incompatible Protocol Versions: a protocol
version with different major version number is
sent.
- Identity Check Failed: an unregistered public
key is used as identity proof.
The handshake should be stopped
immediately as the error is detected, a
detailed error should be signaled to the local
client and a ban time should be set in the IP
Filter. This ban time should be sent along
with a generic error flag to the remote client.
Handshake
protection
mechanisms
SUCCESS
SUCCESS
SUCCESS
The integrity check fails properly on
altered GCM fields.
For the same content being hashed,
the integrity digest match. So when
the content is altered, the digest
doesn’t match anymore, resulting in
a solid integrity check mechanism.
Every test case properly triggered
the protection mechanisms.
SUCCESS
2 • 10
Appendix A: Tests
- Data Corrupted: one of the messages bit is
flipped before decryption.
- Timeout: one of the clients stops to respond
during the handshake.
9
Handshake packet
replay & flood
Test cases:
- Every handshake packet is replayed, one at the
time, each time a different one, until all the packet
are tested for replay property.
- Random packet are sent to the handshake, as
fast as possible.
The handshake should immediately detect
that the packet received is not the one
expected. It should stop the handshake by
reporting a “Data corrupted” error and
doubling the ban time from the last one.
No handshake should be started with the
remote client until the ban time is over.
The flooding increase the ban time
very rapidly, resulting in it to almost
stop after a few attempts.
SUCCESS
3 • 10
Appendix A: Tests
Part 2: GCM-AES encrypted communication
The computer used for the benchmark has the following configuration:
● Intel Core I5 450M 2,4GHz1 (AES-NI not present)
● Windows 8.1 update 2 64bit
● MSVC 2012 - no optimizations
The reference benchmark for the GCM-AES is available on the Crypto++ website2, it was executed on an Intel Core 2 1.83 GHz (AES-NI not present) under
Windows Vista 32-bit. Performances should be a little higher than the reference benchmark on the test machine, but generally similar despite the processor
being a few years younger due to the fact that the Core I5 450M is a laptop aimed processor that has thermic and energy consumption limitation.
Test #
10
11
Description
Test protocol
Expected Result
Sequence IV
generation time
The time generate the IV for the sequence is
measured from the moment the sequence number
is extracted, to the moment where the Sequence
IV is returned. It uses the prototype
implementation.
The reference benchmark states SHA 256:
111 MiB/s
Key + Base IV + Sequence Num = 72 Bytes
72/(111*1024) ≃ 0.63 ms
A random test vector with the length of a AES
block (128 bit) is processed in a encryption/
decryption loop during one second. The number
of loops are counted and multiplied by the block
size at the end to obtain the throughput value.
The reference benchmark states that
AES/GCM should perform around 102 MiB/s
on a single core.
317 MiB/s
Raw performances
1
2
Result
Observations
0.58 ms
The Sequence IV generation is a
little long, maybe a simpler hashing
algorithm could be enough to
guarantee the security of the
private elements and avoid
collisions.
With two cores at 2,4GHz and
hyper-threading, the benchmark
outperform expectations, even
without AES-NI instruction set.
http://ark.intel.com/fr/products/49022/Intel-Core-i5-450M-Processor-3M-cache-2_40-GHz
http://www.cryptopp.com/benchmarks.html
4 • 10
Appendix A: Tests
12
Typical encryption
+ decryption
latency
A random test vector with a 25 KiB length
(arbitrary typical packet size) is generated. The
time used to setup the sequence IV, encrypt, and
decrypt the packet is measured.
With the throughput value found in the test
#11, a value of the time needed for a 25 KiB
packet to be processed.
(1/317) * 0.025 = 0,07ms
Since the packet is processed 2 times
(encryption + decryption) and a sequence IV
is generated the result should be around:
0.58 + (2 * 0.07) = 0.72 ms
13
Packet corruption
A random bit is flipped during the transmission of
the encrypted packet.
The decryption integrity check should fail.
14
Packet loss
A packet is not transmitted during a stream, so
the sequence number skips a number.
The decryption should be done in the next
packets without any troubles
0.76 ms
SUCCESS
SUCCESS
5 • 10
Appendix A: Tests
Part 3: Routing and Apps management
Test #
15
16
17
18
Description
Test protocol
Expected Result
App local
registration test
- A request to start an app is made by
ContactListWindow
- The App is instantiated by the main class, and
registered to the AppManager of the destination
contact.
A pointer to the App should be stored in the
App tables of the main class and of the
AppManager associated with the target
contact.
A request for a remote app to be started with a
local App UID is made.
The App should be started on the remote
client. It should be registered globally and
for the contact, and a route record should
be created in the remote AppManager
routing table.
Then the remote client should send the
route record back to the local client, that in
turns also register the route.
SUCCESS
A request to unregister an App UID is sent to the
remote client
The request is sent, containing the local
App UID that has to be unregistered. The
remote clients should then properly
unregister the route containing the AppUID.
SUCCESS
A packet is received with a registred App UID.
The packet sent by an application should
receive as a header the AppUID of the
remote registered App. The packet should
be encrypted, sent, received, decrypted and
the payload should be passed to the proper
App using its AppUID.
App remote start
App unregistration
Data routing to a
registered App
Result
Observations
SUCCESS
PARTIAL
SUCCESS
The routing behaves inconsistently
when feeded with a continuous
stream of packets. It result in the
first packet being routed while the
other aren’t.
When a packet is sent to from time
to time, it works well except for the
first packet that is not routed
properly.
6 • 10
Appendix A: Tests
Part 4: Instant Messaging App
Test #
19
Description
Test protocol
Expected Result
Result
Observations
Send a message
Send a text string from both Clients
The sent message should be displayed on
the right upper corner while the received
message should be visible in the left upper
corner.
SUCCESS Html could under circumstance be
problematic.
7 • 10
Appendix A: Tests
Part 5: Voice communication App
Test #
20
21
Description
Test protocol
Expected Result
Voice input and
feedback
Using the prototype implementation, the buffer
that contains the acquired sound coming from the
microphone is passed to the sound output object.
It is made sure that the microphone and the
sound output are properly configured by testing
them with any other tool.
The sound recorded by the microphone
should come out of the audio output with a
little to no latency.
The opus encoder parameters are set as
following:
Sampling rate:48KHz
Target bitrate: 25 Kib/s
Frame size: 40ms
Application: Voice
The input sound should be heard on the
audio output with 80ms more latency than
on the test #20.
The audio quality should be a bit less
precise due to the lossy compression but
the speech should be easily
understandable.
Opus encoding and
decoding
Result
SUCCESS
SUCCESS
A sound is recorded by the microphone (a clap,
and various speech sounds) and encoded by
opus.
It is then decoded locally and rendered through
the sound output.
22
23
24
Transmission of
Opus packets over
TCP Link
The encoded Opus packet produced by the test
#21 are sent over the network through a TCP
socket to a remote client where they should be
decoded.
The recorded sound should be played with
slightly higher latency (depending on the
ping time between the two computers)
Transmission of
Opus packets over
UDP Link
Same test as the #22 but over a UDP socket.
Should have the result of the test #22 but
with less latency due to the simplicity of the
UDP protocol.
FAILURE
Command channel
A packet indicating the end of the communication
is sent to the remote client over a TCP Link.
The remote client should end the
communication by pausing the acquisition
and switching its internal and UI state.
SUCCESS
FAILURE
Observations
The delay is really small but
perceptible. Approx.10-20ms.
It depends on the frame size of
the audio interface.
The audio quality was surprisingly
good for such a low bitrate
compared to standard mp3
compression.
Simultaneously recording the
audio input and the output should
allow the measure the precise
latency.
Only an Opus frame arrive. The
cause is probably the bug from the
test #18.
The same routing mechanism
being used as test #22, the same
bug happened.
8 • 10
Appendix A: Tests
Part 6: Video Communication App
Test #
Description
Test protocol
Expected Result
Result
Observations
25
Video acquisition and
feedback
Starting Camera and Displaying the Frames.
What happens before the Camera should be
displayed as fast as possible.
A movement in front of the camera should
be observable with a minimal latency
~100-1000
ms latency
Depending on the workload of
the machine the latency can
vary. Undoubtedly the
implementation could be
optimized.
26
VP8 encoding and
decoding
Measuring the time it takes for a thread to
process a frame and how many frames can be
processed in a minute.
The number of processed frames per
seconds should be above 30.
2-10 fps
The number of processed
frames per second is really low.
Improvements should be made.
Optimize the threads?
Allow more threads to run
simultaneously?
27
Transmission of VP8
packets over TCP
Link
Transferring a stream of frames over TCP and
displaying them on the client.
The frames should be displayed at the same
frequency at which they are sent.
FAILURE
The TCP Link seems not to be
able to handle such a heavy
data stream (bug of the test
#18).
28
Transmission of VP8
packets over UDP
Link
Transferring a stream of frames over UDP and
displaying them on the client.
Transferring a stream of frames over UDP
and displaying them on the client.
FAILURE
The UDP Link seems not to be
able to handle such a heavy
data stream (bug of the test
#18).
9 • 10
Appendix A: Tests
Part 7: Local file storage
Test #
29
30
31
32
33
Description
Test protocol
Expected Result
Result
Observations
File not present
All the files used for local storage are deleted.
settings.ini, contacts.db3, keystore.dat
The client should behave as if it was started
for the first time and should display the
configuration wizard.
SUCCESS
If only one of the file is missing
the configuration wizard is also
displayed.
Four different test are made:
- flipping random bits of the password hash
- flipping random bits of the salt
- deleting the password hash
- deleting the salt
In every case, the key to decrypt the storage
that is generated by the password and using
the salt should not be the same than the
one used to encrypt the storage, resulting in
the program failing to read them and open
with no contact and no Keyring.
SUCCESS
The password is changed using the proper
function of the settings dialog.
The password should be hashed and the
hash saved in settings.ini.
A new file key should be generated, and the
Keystore and the whole contact database
should be re-encrypted using the new key.
SUCCESS
The Keystore decryption should fail on the
GCM integrity check. The Keystore file
should be rejected, and the configuration
wizard should appear to invite the user to
generate a new RSA key pair.
SUCCESS
Change password
hash or salt
Change password
Keystore content
altered
Contact database
entry altered
Random bits of the keystore.dat file are flipped.
A contact entry in the database is changed.
The whole database file should be rejected
on the integrity check, resulting in the loss of
all the contacts.
SUCCESS
A per contact integrity digest
should allow the unaltered
entry to survive. At the cost of
the digest computation, this
being proportional to the
number of contacts
10 • 10
Appendix B: References
GCM
Wiki
http://en.wikipedia.org/wiki/Galois/Counter_Mode
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propose
dmodes/gcm/gcm-spec.pdf
AES and RSA
AES Wiki
http://de.wikipedia.org/wiki/Advanced_Encryption_Standard
Online testing tool
http://aesencryption.net/
AES analysis
http://research.microsoft.com/enus/projects/cryptanalysis/aesbc.pdf
AES on Intel
https://software.intel.com/en-us/articles/intel-advancedencryption-standard-instructions-aes-ni
RSA Wiki
http://en.wikipedia.org/wiki/RSA_(cryptosystem)
News on cryptographic
security
http://www.nist.gov/itl/csd/sp800-90-042114.cfm
http://www.nytimes.com/2013/09/06/us/nsa-foils-muchinternet-encryption.html?_r=0
http://en.wikipedia.org/wiki/Dual_EC_DRBG
Network
http://de.wikipedia.org/wiki/Transmission_Control_Protocol
http://de.wikipedia.org/wiki/User_Datagram_Protocol
http://de.wikipedia.org/wiki/Real-Time_Transport_Protocol
Libraries
Libvpx
http://www.webmproject.org/docs/vp8-sdk/
Crypto++
http://www.cryptopp.com/
Opus Interactive Audio
Codec
http://www.opus-codec.org/
Jrtplib
http://research.edm.uhasselt.be/jori/page/index.php?n=CS.Jrt
plib
1•2
Similar projects
TOX
https://tox.im
Bleep
http://labs.bittorrent.com/experiments/bleep/index.html
Qt
http://qt-project.org/
Qt Creator
https://qt.gitorious.org/qt-creator
CMake
http://www.cmake.org/
MSVC2012
http://en.wikipedia.org/wiki/Visual_C%2B%2B
SQL
http://de.wikipedia.org/wiki/SQL
Tools
Project Website
http://web.fhnw.ch/technik/projekte/eit/Fruehling2014/KlePic/
Project GitHub
http://github.com/thomas-picariello/SDTP
Books
Practical Cryptography - Ferguson & Schneier
2•2
Appendix C: Contingency Plan
Appendix C: Contingency Plan
Possible bottlenecks
Alternative Solution(s)
CMake building issues
Use the less convenient QMake
Data Routing
Use a different Socket per App
Opus voice encoding
Use audio encoder provided by Qt
VPx video encoding
Use video encoder provided by Qt
RTP Protocol
Use UDP or TCP for streaming
UPnP NAT
Use NAT-PMP or manual configuration
Performance or security issues in
cryptographic implementation
1.
2.
2.
3.
Local encrypted data storage
Use clear text xml
API oriented implementation
Use integrated implementation
Optimize the implementation
Use well-tested snippets
Use a different cryptographic library
Lower the global security level
1•1

Secure Data Transfer Protocol v0.1

Transcription

Similar documents

Able2Extract Mobile on iOS

Go www.boyscoutscampcard.com

oking Masked crusad er lo o too wine and din e... C a M ng, of eeks

VSCO CAM - Camryn Prows Photos

ePlayslip Quick Reference Sheet

XH558 4.0 Features - Vulcan To The Sky

MobiGuide: Homecare per Pazienti con Fibrillazione Atriale

APPSTORES ARE DEAD_Seifert

4. Select the “My Lexile Range” drop down. Now, click search. 2

restaurant mobile apps must include