Spot-On Echo Communications Software Introduction ................................................................................................................................................ 4 Accounts ..................................................................................................................................................... 5 Adaptive Echo ............................................................................................................................................ 6 Block Cipher Modes of Operation ............................................................................................................. 7 Capabilities Sharing ................................................................................................................................... 8 Cascading Encryption ................................................................................................................................ 9 Communication Methods ......................................................................................................................... 10 Communication Model ............................................................................................................................. 11 Communication Sessions ......................................................................................................................... 12 Compilation Process ................................................................................................................................ 13 Configuration Settings ............................................................................................................................. 14 Constant-Time Comparison Function ...................................................................................................... 15 DTLS ........................................................................................................................................................ 16 Echo ......................................................................................................................................................... 17 Echo Public Key Sharing ......................................................................................................................... 18 Electronic Mail ......................................................................................................................................... 19 Electronic Mail Forward Secrecy ............................................................................................................. 20 Encrypted and Authenticated Containers ................................................................................................. 21 File Encryption ......................................................................................................................................... 22 Forward Secrecy ...................................................................................................................................... 23 Fragmented StarBeams ............................................................................................................................ 24 GPG .......................................................................................................................................................... 25 Key Derivation ......................................................................................................................................... 26 Hybrid System .......................................................................................................................................... 27 Kernel ....................................................................................................................................................... 28 Local Private Application Interfaces (Patch Points) ................................................................................ 29 McEliece .................................................................................................................................................. 30 Multicasting ............................................................................................................................................. 32 Multiple Devices ...................................................................................................................................... 33 Non-Volatile Congestion Control Memory .............................................................................................. 34 NTL .......................................................................................................................................................... 35 Other Options ........................................................................................................................................... 36 Pass-through Devices ............................................................................................................................... 37 Poptastic ................................................................................................................................................... 38 Problems ................................................................................................................................................... 39 Public Key Infrastructure ......................................................................................................................... 40 Public Key Sharing .................................................................................................................................. 41 Pure Forward Secrecy .............................................................................................................................. 42 Secure Memory ........................................................................................................................................ 43 Sessions .................................................................................................................................................... 44 Socialist Millionaire Protocol .................................................................................................................. 45 Sources of Entropy ................................................................................................................................... 46 Surreptitious Forwarding ......................................................................................................................... 47 Two-Way Calling ..................................................................................................................................... 48 UI Fields ................................................................................................................................................... 49 Verifying Ownership of Public Keys ....................................................................................................... 50 Wide Lanes ............................................................................................................................................... 52 References ................................................................................................................................................ 53 Introduction Spot-On is a dolphin-propelled science project. The software is composed of two separate applications, a multitasking kernel and a user interface. The two applications are written in C++ and require the Qt framework as well as an assortment of libraries. Qt versions 4.8.x and Qt 5.x are supported. Spot-On is available on FreeBSD, Linux, OS X, OS/2, and Windows. In addition to supporting the x86 and x86-64 architectures, ARM, PowerPC, and SPARC are supported without any special provisions. Please note that the Echo algorithm and its name are not derived from Ernest J. H. Chang's 1982 Echo Algorithms: Depth Parallel Operations on General Graphs paper. Software source is available at https://github.com/textbrowser/spot-on Accounts Spot-On implements a plain, and perhaps original, two-pass mutual authentication protocol. The implementation is well-defined with or without SSL/TLS. Synchronized clocks are required. The protocol is weakened if trusted SSL/TLS is neglected, however. Please see the paragraph at the end of this section for additional details regarding the weakness. The protocol has at least two disadvantages. First, account information is stored in authentically-encrypted containers. Second, the process of discovering the provided account is iterative. Both problems offer insight to an adversary. The Accounts procedure is as follows: 1. Binding endpoints are responsible for defining account information. During the account- creation process, an account may be designated for one-time use. Account names and account passwords each require at least 32 bytes of data. 2. After a network connection is established, a binding endpoint notifies the peer with an authentication request. The binding endpoint will terminate the connection if the peer has not identified itself within a fifteen-second window. 3. After receiving the authentication request, the peer responds to the binding endpoint. The peer submits the following information: H Hash Key (Salt || Time) || Salt, where the Hash Key is a concatenation of the account name and the account password. The SHA-512 hash algorithm is presently used to generate the hash output. The Time variable has a resolution of minutes. The peer retains the salt value. Please note that the peer may submit credentials without having received an authentication request. This is acceptable. 4. The binding endpoint receives the peer's information. Subsequently, it computes H Hash Key (Salt || Time) for all of the accounts that it possesses. If it does not discover an account, it increments Time by one minute and performs an additional search. If an account is discovered, the binding endpoint creates a message similar to the message created by the peer in the previous step and submits the information to the peer: H Hash Key (Salt || Salt 3 || Time) || Salt. The authenticated information is recorded. After a period of approximately 120 seconds, the information is discarded. 5. The peer receives the binding endpoint's information and performs a similar validation process, including the analysis of the binding endpoint's salt. The two salt values must be distinct. The peer will terminate the connection if the binding endpoint has not identified itself within a fifteen-second window. Peers will ignore unsolicited authentication requests. Please note that the Accounts system may be promoted by including an encryption key. The additional key will allow for finer time resolutions. If SSL/TLS is not available, the protocol may be exploited. A relay station may record the values in the 3 rd step and subsequently provide the information to the binding endpoint. The binding endpoint will therefore trust the foreign connection. The recording device may then seize the binding endpoint's response, the values in the 4 th step, and provide the information to the peer. If the information is accurate, the peer will accept the binding endpoint's response. Therefore, the Accounts protocol is susceptible to impersonation. The use of nonces and timestamps, in conjunction with congestion control and the retaining of distributed nonces, should prevent reflection, reordering, and replay attacks. Adaptive Echo The Adaptive Echo is a complement to the Echo and substantiates the opinion that the Echo is a malleable method. Endpoints that bind multiple parties may optionally define Adaptive Echo tokens. Adaptive Echo tokens are composed of authentication and encryption keys as well as details about the choice algorithms. If configured, binding endpoints are able to permit or restrict information travel based on the content of the data. As an example, peers that are cognizant of a specific Adaptive Echo token will receive data from other cognizant peers whereas traditional peers will not. Binding endpoints therefore selectively-echo data. The Adaptive Echo behaves as follows: 1. A binding endpoint defines an Adaptive Echo token. The information must be distributed securely. 2. A networked peer having the given Adaptive Echo token generates H Hash Key (E Encryption Key (Message || Time)) || E Encryption Key (Message || Time) where the Encryption Key and Hash Key are derived from the Adaptive Echo token. The generated information is then submitted to the binding endpoint as Message || Adaptive Echo Information. 3. The binding endpoint processes the received message to determine if the message is tagged with a known Adaptive Echo token. If the message is indeed tagged correctly, the Time value is inspected. If the Time value is within five seconds of the binding endpoint's local time, the message is considered correct and the peer's presence is recorded. 4. As the binding endpoint receives messages from other peers, it inspects the messages to determine if the messages have been tagged with Adaptive Echo tokens. This process creates a network of associated peers. Because peers themselves may be binding endpoints, the Adaptive Echo may be used to generate an artificial trust network. Adaptive Echo is susceptible to eavesdropping. As an example, if a message that is tagged with an Adaptive Echo token should travel through one or more peers to reach a destination, the peers may record the message and subsequently replay the message to a binding peer. The replay must occur within the acceptance window of the message. Additionally, the binding endpoint's congestion control container must not already contain the message. If both conditions are met, the binding endpoint will consider the peer as trustworthy. Block Cipher Modes of Operation Spot-On uses CBC with CTS to provide confidentiality. The file encryption mechanism supports the GCM algorithm without the authenticity property that's provided by the algorithm. To provide authenticity, the application uses the encrypt-then-MAC (EtM) approach. The Encrypted and Authenticated Containers section provides more details. Capabilities Sharing Peers may exchange capabilities information. Currently, the information includes the UUID, the echo mode, and the preferred lane width. Please note that a server socket must adhere to its peer's settings. Although an administrator may modify the echo mode and the lane width on a particular socket (remote neighbor), the kernel will override the settings so as to conform to the client's preferences. Cascading Encryption Spot-On implements multiple encryption. The general implementation is as follows: 1. If available, retrieve previously-established authentication and encryption keys. 2. Retrieve random authentication and encryption keys. Verify that the random credentials differ from those in step #1. 3. Generate a hybrid bundle: RSA(#2) || AES(message) || HMAC(RSA(#2) || AES(message)). Some variations are also possible. Camelia, Gost, Serpent, Threefish, and Twofish cipher algorithms are supported. As for digest algorithms, SHA, Stribog, and Whirlpool are included. 4. Generate a bundle from the data in step #3 using the keys from step #1: AES(#3) || HMAC(AES(#3)). 5. If SSL/TLS is available, funnel the bundle from step #4 through the SSL/TLS layer. Communication Methods Spot-On supports Bluetooth, SCTP, TCP, UDP (multicast and unicast), and WebSocket communication methods. Both IPv4 and IPv6 are totally supported. Some communications portions also support a variety of proxies. For TCP, UDP unicast, and WebSocket communications, OpenSSL is supported. Spot-On distributes data with or without SSL/TLS. Please note that magnet distribution violates this principle and therefore requires SSL/TLS. In essence, the application is generally transport-neutral. Please note that Bluetooth and SCTP support require operating system support. Communication Model Spot-On mostly assumes an asynchronous communication model. The Accounts, SMP, and Two-Way Calling systems require responses. Communication Sessions This section describes some common methods which may be employed against Spot-On in an attempt to destabilize the communications of two parties. Various attack methods include: flood attack, re-ordering attack, reflection attack, and replay attack. Public Spot-On devices are susceptible to flood attacks. Save for Local Private Application Interfaces , Spot-On does not guarantee orderly delivery of data and is therefore susceptible to re-ordering . However, this attack method is not considered detrimental as Spot-On is not orderly. Some sub-systems such as Accounts and SMP should be resistant to this particular attack. In a reflection attack , an adversary may capture a message sent from party A to party B and return the message to party A. For this attack to be successful in messages involving public keys, it must be possible for the originator of the message to be able to decipher its original message. Private-key communications are susceptible to reflection attacks, however, digital signatures, properly-defined congestion control and timestamps will protect against reflection attacks. In a replay attack, an adversary may replay a valid message. Discounting congestion control, the message may appear as if it was sent recently. All private-key portions of Spot-On contain timestamps. Most public key portions also contain timestamps, e-mail being an exception. Congestion control and timestamps should provide some resistance against replay attacks. Computing and memory resources are required to prevent the aforementioned attacks. Compilation Process Spot-On builds are not digest-reproducible as the compilation process embeds the date and time of the compilation. In order to produce digest-reproducible builds, the SPOTON_DATELESS_COMPILATION option should be enabled during the generation of the project files. For example, qmake DEFINES+=SPOTON_DATELESS_COMPILATION -o Makefile spot- on.qt5.pro. One should then expect results similar to the following. date && sha512sum ./Spot-On ./Spot-On-Kernel Fri Jan 6 10:27:21 2017 0fbcf8e8a82dacd9825c42cf88d2d5a70d87965da20a3bfc5f87b8f634e0219567ecd42a01a30b55aed438d 6c55ab1d4a6d7ea62fe7a65ac461874f1f1c5de59 ./Spot-On 0cf523d52de5f50ec01e7f442c0f374ac15b6432757f17ac93df26f88784d5819f27101a10a6e765b4d7e8c a420b7c110e822dc835ad0083b339b64f1431ec81 ./Spot-On-Kernel date && sha512sum ./Spot-On ./Spot-On-Kernel Fri Jan 6 10:28:47 2017 0fbcf8e8a82dacd9825c42cf88d2d5a70d87965da20a3bfc5f87b8f634e0219567ecd42a01a30b55aed438d 6c55ab1d4a6d7ea62fe7a65ac461874f1f1c5de59 ./Spot-On 0cf523d52de5f50ec01e7f442c0f374ac15b6432757f17ac93df26f88784d5819f27101a10a6e765b4d7e8c a420b7c110e822dc835ad0083b339b64f1431ec81 ./Spot-On-Kernel Non-digest-reproducible builds will generate distinct results. date && sha512sum ./Spot-On ./Spot-On-Kernel Fri Jan 6 10:30:43 2017 4ccc44773bd43086941dd26f02b82e2eca7972f768844a544d23c19fedf6ed407911a73af4493c546c9bf9 4ec60afd69c5e0a646e8f9378c75811f4b4d36ef9e ./Spot-On 90720de4702bd5df97ce1af6ec5fd8ec206b279fecff37200f5bad5849e4e1183131ef7492a3a94f45db648e a415184e1ab89da76e7ca9d493738de37e6a8bb5 ./Spot-On-Kernel date && sha512sum ./Spot-On ./Spot-On-Kernel Fri Jan 6 10:32:10 2017 ea6275a644d1cd589510907929d8133b9e4557abca8c19aa4523887d0efe2b084f24b80216e5b3c889d23 d0071afbac1933b772bae5f7cdbb58bd383be4a4a8e ./Spot-On 51d59a7dccd39a34183eeb200e2658d3d77a24e4ca5facbb9ee95fb8f32dbb7434f2d354342c5d7fefd0104 feeda45fad6a9fe33a81ee6cd5cf76619a44932e5 ./Spot-On-Kernel Configuration Settings Spot-On implements a defensive approach with respect to configuration settings. Shortly after the kernel and the user interface are started, important settings are reviewed and if necessary corrected. The potentially-adjusted values are stocked in global containers. Some methods also inspect critical values, adjusting them if necessary. Constant-Time Comparison Function Spot-On attempts to utilize constant-time byte comparison functions so as to avoid timing analysis. Comparisons that occur within database queries are not guaranteed to be constant-time. DTLS Spot-On supports DTLS over unicast. Qt version 5.12, or newer, is required. Echo Spot-On introduced the Echo. The Echo is a malleable concept. That is, an implementation does not require rigid details. Each model may adhere to their own peculiar obligations. The Echo functions on the elementary persuasion that information is dispersed over multiple or singular passages and channel endpoints evaluate the suitability of the received data. Because data may become intolerable, Spot-On implements its own congestion control algorithm. Received messages that meet some basic criteria are labeled and duplicates are discarded. Advanced models may define more sophisticated congestion- avoidance algorithms based upon their interpretations of the Echo. Spot-On provides two modes of operation for the general Echo, Full Echo and Half Echo. The Full Echo permits absolute data flow. The Half Echo defines an agreement between two endpoints. Within this agreement, information from other endpoints is prohibited from traveling along the private channel. Echo Public Key Sharing The Echo Public Key Sharing construct was introduced by Mr. Schmidt. It is an elegant compliment to the Echo. The concept may be summarized as follows: 1. A community is created. The community is defined by a pair of authentication and encryption keys. The keys are derived via the PBKDF2 function. 2. Public key pairs may be optionally exchanged via the community. Participants who subscribe to a well-defined community will automatically accept public key pairs from participants who have published their public keys to the respective community. Electronic Mail Spot-On provides two e-mail models for distributed e-mail. Endpoints may optionally define themselves as institutions or post offices, or both. A brief description of e-mail institutions follows. E-mail institutions are artificially characterized by addresses and names. The information is not considered secret and several endpoints may identify themselves identically. It is the responsibility of an institution to define subscribers. The data that an institution houses is stored in encrypted containers. Unlike physical institutions, Spot-On institutions are only allowed to read the signature portions of e-mail letters. The signatures allow verification of deposits and withdrawals. One important difference between e-mail institutions and e-mail post offices is that post offices require the distribution of public keys. Electronic Mail Forward Secrecy This section briefly describes a two-step communication process for establishing forward secrecy in Spot-On e-mail. We assume a hybrid scheme with respect to public key encryption. Assumptions: 1. Permanent public key pairs have been exchanged correctly. 2. The respective kernels remain active during the exchange window. Protocol: 1. Participant A generates an ephemeral public key pair. The key pair's attributes are configurable. If the kernel is deactivated after the key pair is generated, the key pair is discarded and the protocol is terminated. 2. Participant A transmits the ephemeral public key to B. The key is encrypted with B's permanent encryption public key and optionally signed with A's permanent private signature key. 3. B receives the public key and optionally verifies the signature. If B requires a valid signature but one is not provided, the protocol is terminated. 4. B generates private authentication and encryption keys. The keys are recorded locally. 5. Using the ephemeral public encryption key, B transfers the keys to A. The complete bundle is encrypted with A's permanent encryption public key and optionally signed with B's permanent private signature key. 6. Participant A receives the bundle and optionally verifies the signature. If A requires a valid signature but one is not provided, the protocol is terminated. The session keys generated in the fourth step may remain in use until one of the parties decides to establish new session keys. Signatures are required over the Poptastic transport.