Advanced Security for Internet of Things with IoTAS

Transcription

1 WHITE PAPER Advanced Security for Internet of Things with IoTAS An alternative to SSL/TLS Luis Paris, Ph.D. Chief Scientist Centri Technology, Inc th Ave, Suite 550 Seattle, WA luis@centritechnology.com

2 ABSTRACT This paper introduces Centri s new IoTAS solution for secure communications, and contrasts it with the SSL/TLS protocol. A brief overview of SSL/TLS is provided along with the most common key exchange methods used in the protocol. The pros and cons of SSL/TLS are then discussed along with some of the vulnerabilities encountered in well-known implementations, such as OpenSSL. IoTAS s key exchange model is then discussed, where session keys are derived and exchanged using both public key cryptography and a pre-shared seed library that resides in both trusted endpoints and servers. Finally, the paper discusses how IoTAS is able to transcend the transport layer by allowing trusted endpoints to encrypt, store, and access encrypted content with a remote server. The secure storage is driven by an application layer module that cooperates with IoTAS to provide single or multiple shared access to remote encrypted files. Keywords Cryptography; Data Encryption; Key Exchange; SSL; TLS; Data Compression; Key Management; Secure Protocol. 1. INTRODUCTION SSL (secure sockets layer) and TLS (transport layer security) are well-known cryptographic protocols for creating secure channels for endpoints and servers to communicate confidentially. SSL is outdated nowadays and superseded by TLS which fixed a number of vulnerabilities. However, TLS can still be considered a form of secure sockets and, in fact, some known attacks can potentially downgrade a TLS session to SSL, allowing the latter, in theory, to be used surreptitiously instead of TLS, even when the latter was requested. This would make it possible to carry out potential SSLspecific attacks on secure connections supposedly protected with TLS. For these reasons, although SSL is outdated and TLS is the current protocol, this paper refers to both simply as SSL/TLS, unless explicit clarification is required. SSL/TLS provides three basic, essential services: authentication, encryption, and data integrity. Authentication provides a way to verify the identity of the server, encryption allows confidentiality of the message, and integrity provides a way to detect message forgery or tampering. Unfortunately, the one size fits all design of SSL/TLS has contributed to added latency and has exposed the protocol to additional security holes and vulnerabilities. Most of these are well documented. Two of the most important exploits are covered here. In contrast, IoTAS provides a fourth optional service: a secure cloud storage feature using a cipher module with one-pass data optimization/encryption. 1.1 Is SSL/TLS the right choice? One of the reasons why SSL/TLS is particularly prone to potential vulnerabilities and man-in-the-middle attacks is that the protocol makes the strict assumption that endpoints will attempt their secure connections over anonymous, untrusted devices. This has the disadvantage that no device or application specific information can be pre-shared on the endpoint or server during the SSL/TLS key exchange. Consequently, in a typical SSL/TLS handshake, all input required to the key material for encryption and decryption is sent over the network and exchanged in order to establish the secure connection. This is fine for most ecommerce applications where e-shoppers and online purchases come and go. However, it is certainly not the best model for real-time financial applications where thousands of secure connections are spawned from trusted endpoint devices, or from registered nodes within mesh networks. This is only expected to exacerbate further as emerging technologies continue their ongoing shift towards the internet-of-things paradigm, where interconnected devices and machines will exchange data regularly and securely from anywhere at any time. 1.2 SSL/TLS Overview The goal of SSL/TLS is to create a secure channel for endpoint and server to communicate securely using a communication protocol. Therefore, SSL/TLS is just a cryptographic protocol that encrypts and encapsulates traffic d by a second protocol. The most common choice for that second communication protocol is HTTPS (HTTP over SSL/ TLS), although in theory, any digital communication protocol can be used; e.g. FTPS (FTP over SSL). Since the communication protocol can operate with or without SSL/TLS, it is necessary for the endpoint to notify the server that an SSL/TLS secure session is requested. HTTPS reserves TCP port 443 for this, which is also a potential weakness as it is one of the most targeted ports used for distributed denial of service (DDoS) attacks. After an SSL/TLS connection is requested, the handshake begins, which negotiates the cryptographic functions to use for encryption and decryption. Ciphersuites are used for this, which define a set of authentication, key exchange, hash function, and session cipher algorithms that endpoint and server will agree to use during the initial handshake, and thereafter during the secure session itself. 1.3 IoTAS Overview IoTAS includes an advanced cryptographic protocol for creating secure connections between trusted endpoints over an insecure network. When compared to open source, IoTAS consists of a faster, more efficient Ciphersuite, hosting advanced cryptographic functions, developed in-house, for key hashing, public key exchange, message authentication, and fast data optimization/encryption. IoTAS relies on both asymmetric cryptography and pre-shared content data to perform the key exchange and derivation. The preshared data consists of a seed library pre-embedded at both endpoint and server where IoTAS is installed. This deployment model allows for a faster, more convenient setup vs. SSL/TLS. In its current state, IoTAS can be implemented as an independent protocol in place of SSL/TLS - the recommended option, or as a ciphersuite within SSL/TLS. In a nutshell, IoTAS provides: Lower latency for connection and session. Lightweight deployment and operation. Faster, more secure encryption/decryption. Seamless data optimization/encryption. Stronger, more efficient key exchange/derivation. No third-party certificate authorities involved. Works at transport and application storage level. Table 1 below shows the key differences between IoTAS and SSL/TLS in terms of protocol speed, overall security, connection and session latency, optional data optimization, and whether the protocol supports or cooperates to support secure remote storage. 2

3 Table 1. Differences between IoTAS and SSL/TLS. Protocol Speed Security Latency Data Optimization 2. IoTAS vs. SSL/TLS Secure Storage IoTAS Fast High Low Yes Yes SSL/TLS Slow Medium High No No The main goal of any secure connection protocol is to create a virtual channel for confidential communication to flow between two points. IoTAS goes beyond this basic goal by providing the following additional benefits over SSL/TLS. 2.1 Protocol Speed The performance of SSL/TLS depends to a large extent on the speed and efficiency of the ciphersuite agreed by endpoint and server during the connection handshake. This is mostly where IoTAS stands out over SSL/TLS. IoTAS uses its own speed optimized algorithms for key exchange, authentication, hashing, and encryption. This results in much faster performance during any of the steps of the connection handshake, invariably. This also includes a faster encryption stage for the remainder of the secure session. IoTAS significantly outperforms SSL/TLS due to its simplified handshaking see Section Protocol Security SSL/TLS has been a target for notable backdoor and vulnerability exploits over the years. The weakest link in SSL/TLS is the key exchange. The main reason is that SSL/TLS considers any endpoint or device to be untrusted by definition. Consequently, in its default operation mode, the SSL/TLS key exchange must rely solely on information sent and exchanged over the network; no preshared content is considered safe since the device is untrusted. Therefore, if the key exchange algorithm is already known and the server s public key has been compromised, then in theory, that particular system is prone and open to man-in-the-middle attacks Man-in-the-middle attack in SSL/TLS Imagine a device sitting between the endpoint and server, capable of emulating SSL/TLS connections. From the endpoint s point of view, a secure connection was established with a server. However, it is possible that a man-in-the-middle device could be negotiating the actual connection to the secure server on behalf of the endpoint. Such a device would then be able to monitor the endpoint surreptitiously IoTAS s public key and pre-shared content IoTAS is installed on a trusted device and a trusted server. This creates a unique opportunity to strengthen virtually any aspect of the secure protocol and the secure session it hosts. To that end, IoTAS does not only rely on public key cryptography to exchange data securely during the key exchange. It also relies on pre-shared content present at both endpoint and server to derive the key material for the encrypted session. In other words, if the sole use of public key cryptography makes it hard already to break the session key, the addition of pre-shared data in the form of a dynamic seed library makes it even harder to break into the secure session, let alone hijack it. IoTAS implements the best of both worlds public key cryptography with custom pre-shared content to further secure and obfuscate the key exchange, derivation, and cipher IoTAS Cipher IoTAS features a high-speed, state-of-the-art, stream-based cipher and a very efficient cryptographic key-to-hash function. This makes IoTAS outperform virtually any SSL/TLS ciphersuite in terms of cipher speed, handshake efficiency, CPU performance, and overall security over SSL/TLS due to the use of pre-shared 3 content and public key cryptography. Figure 1 below shows a system diagram of the IoTAS cipher. Figure 1. IoTAS stream-based cipher 2.3 Connection Latency and Session Latency Latency is defined as the delay incurred in providing input to the system and the release of the expected output. In the context of any secure protocol, system latency builds up mostly during key exchange, derivation, and during the secure session itself when data is encrypted and decrypted. Both latency types are covered next and how IoTAS and SSL/TLS cope with both types Connection Latency The latency incurred during the initial handshake when the keys are exchanged is known as the connection or handshake latency. It is typical from the key exchange stage of any secure protocol. Figure 2 below shows a simplified view of the key exchange for IoTAS and SSL/TLS. Note that SSL/TLS requires at least four messages to share the key successfully between the endpoints. In contrast, IoTAS requires only two messages, each message spawning one action, each action taking significantly less time to derive the session keys as compared to SSL/TLS. So, handshake latency in IoTAS is reduced not only from executing each action faster, but also from exchanging fewer messages as well. However, if IoTAS were set to operate as a ciphersuite within SSL/TLS, it would require at least four messages as most other ciphersuites. In this scenario, IoTAS would still perform better than SSL/TLS, but worse than IoTAS as a standalone protocol. endpoint centri ID + platform ID + endpoint pub key /server pub key symmetric session key from instruction set IoTAS Endpoi nt 1 2 Server authenticate endpoint, instruction set instruction set /endpoint pub key symmetric session key from instruction set Endpoi nt Server EndpointHe llo + list of 1 ServerHello + ciphersuites certificate + 2 ServerHelloDone EndpointEx change + ChangeCip herspec + Finished symmetric key from exchanged material SSL/TLS Figure 2. Key Exchange messages in IoTAS vs. SSL/TLS 3 4 ChangeCipherSp ec + Finished symmetric key from exchanged material

4 Therefore, IoTAS as a full secure standalone protocol is the recommended option instead of IoTAS running as an SSL/TLS ciphersuite Session Latency The session latency depends primarily on the efficiency of the cipher used to encrypt and decrypt the session data, and the cipher characteristics stream vs. block based, block size, etc. In the case of SSL/TLS, most of the ciphers are block-based: AES, Camellia, ARIA, GOST, etc. The only exception is the ChaCha20 stream cipher, but it is still in RFC draft proposal. In summary, latency will be higher for a block cipher than for a stream cipher. IoTAS features a high-speed stream cipher capable of performing both data optimization and encryption in a single pass of the plaintext data see Figure 1 above. The main advantage is that the memory buffer that contains the plaintext is processed only once, without the need for internal buffering. This allows IoTAS s stream cipher to reduce session latency more effectively and efficiently than any SSL/TLS block-based cipher. 2.4 Optional Data Optimization An optional but desirable feature of a secure connection protocol is the ability to optimize the plaintext stream before encrypting it. Implementing data optimization brings further savings in terms of reduced stream footprint and increased effective bandwidth. Unfortunately, the default ciphersuites in SSL/TLS do not support data optimization. In contrast, IoTAS supports an efficient data optimization model that integrates seamlessly with IoTAS s stream cipher or any other external stream-based cipher. In short, IoTAS s one-pass optimization and encryption provides the following benefits: Blended data optimization/encryption implemented as a single functional unit running one task only. Data optimization/encryption performs one pass; input data is optimized and encrypted within the same loop. Stronger encryption; less prone to vulnerabilities since encryption depends on the internal compression state. Lower system footprint; no extra buffering required; no additional initialization of separate processes or tasks. 2.5 Secure Storage Another key advantage of IoTAS over SSL/TLS is the ability to go beyond the transport layer barrier by cooperating with a file encryption module located at the application layer. This allows encrypted file streams to be stored securely and seamlessly within the cloud. Even more so, this would be able to prevent most of the increasingly common data breaches where millions of private records are compromised every year as a result of storing critical data unencrypted on permanent storage disks and databases. In contrast, SSL/TLS can only secure the data within the transport layer of the endpoint-server communication loop, that is, within the confines of the physical/virtual network. Once the message stream leaves the network, SSL/TLS cannot secure the data anymore. 3. SSL/TLS Handshake The basic handshake consists of a four message sequence, with the endpoint initiating the first message. After the handshake, the encrypted data is encapsulated within fixed size blocks called TLS records and protected with a message authentication code (MAC). Each of the four messages is a compound of various message types, selected from the following list: HelloRequest 4 EndpointHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone CertificateVerify EndpointKeyExchange Finished The four-message handshake is as follows: 1. Endpoint Server: EndpointHello Endpoint sends a EndpointHello message containing: List of supported ciphersuites in order of preference. EndpointRandom: 32 bytes (256 bits) of random data. 2. Server Endpoint: ServerHello, Certificate, [CertificateRequest], ServerHelloDone Server selects first mutually supported ciphersuite. ServerRandom: 32 bytes (256 bits) of random data. Server must send its X.509 certificate, which is the server public key signed by a root of trust, or by a CA in a chain of CA's to a root of trust. The server might send other certificates in the chain of trust toward a root of trust. The CertificateRequest message is optional and it is sent by the server if it requires endpoint credentials; the endpoint cannot push its credentials to the server, they must be requested by the server using this message. The ServerHelloDone is needed because the server might send optional components before. 3. Endpoint Server: EndpointKeyExchange, [Certificate, CertificateVerify], ChangeCipherSpec, Finished Endpoint chooses a 48 byte PreMasterSecret, of which 46 bytes are random data, encrypts it using server's public key found in the X.509 certificate, and sends it to server in a EndpointKeyExchange message. If the server requested endpoint credentials in step two above, the endpoint must send both its certificate and a CertificateVerify message in its EndpointKeyExchange message. The CertificateVerify message is endpoint's signature on a hash of all handshake messages, including the endpoint and server random values. A ChangeCipherSpec message, the last unencrypted record. A Finished record, encrypted and MAC ed using the negotiated keys, to authenticate the parameters and seal the handshake with hash values. 4. Server Endpoint: ChangeCipherSpec, Finished Server sends a ChangeCipherSpec as the last unencrypted record it will send. Server then sends an encrypted Finished record, encrypted and MAC ed with the negotiated keys, to authenticate the parameters and seal the handshake with hash values.

5 4. IoTAS Handshake The IoTAS handshake for the key exchange consists of only two messages, as depicted in Figure 3 below. The handshake sequence is initiated the first time a IoTAS connection is requested, or whenever a session reinitiates. Figure 3. The IoTAS two-message key exchange handshake. Messages flowing from endpoint to server are encrypted with the server s public key which is pre-embedded in the endpoint. Responses sent from server to endpoint are encrypted with the endpoint s public key. After the endpoint connects to establish a IoTAS session, the twomessage handshake begins, as follows: 1. Endpoint Server: Centri ID + Platform ID + endpoint pub key The Centri ID, the Platform ID, and the endpoint public key are encrypted and sent to the server. The Centri ID identifies the unique application IoTAS is coupled with. The Platform ID identifies the unique device where the endpoint runs. The endpoint public key allows the server to encrypt messages back to the endpoint. 2. Server Endpoint: Endpoint ID + instruction set for key genj. IoTAS Session Established! The server authenticates the endpoint from the Centri ID and Platform ID that was sent by the endpoint. If valid, the server s a unique Endpoint ID and an initial instruction set for key generation. The server encrypts both, and sends them back to the endpoint. The Endpoint ID is a cryptographic hash created from at least the Centri ID and the Platform ID. It is used to identify the endpoint quickly during successive requests. The instruction set is d by the server using a non-deterministic random bit generator (NDRBG). The instruction set consists of: a) Seed file ID identifies which seed file in the pre-embedded seed library to use. b) Passphrase offset offset in bytes from the beginning of the seed file selected. c) Passphrase length number of bytes to read from the seed file selected. The pre-shared seed library consists of up to 16 pseudo randomly d (PRG) seeds containing uniformly distributed random data. The PRG seed files 5 are d from the actual seed files used in the cipher when run in optimization/encryption mode. From the instruction set received by the endpoint, both endpoint and server independently decode the instruction set into the three fields above, extract the passphrase, and /derive the key material to be used for encryption and decryption during the secure session. What is unique about the IoTAS key exchange is that since the trusted endpoint device and the server run preinstalled software on both endpoints, the key exchange is much more secure than SSL/TLS due to the presence of pre-shared content at both Endpoint and Server. This discards any potential man-in-themiddle attack that relies solely on data interception/monitoring during transit. 5. SSL/TLS Ciphersuites During the key exchange handshake, the endpoint sends a list of ciphersuites supported by endpoint within the EndpointHello message. This list, which is a potential vulnerability in itself, is specified in readable ASCII text (another weakness) and includes four fields, the algorithms for: authentication, encryption, hashing, and key exchange. This is a typical EndpointHello message sent to the server: EndpointVersion 3,1 EndpointRandom[32] SessionID: None (new session) Suggested Cipher Suites: TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA Suggested Compression Algorithm: NONE In the above example, TLS_RSA_WITH_DES_CBC_SHA is one of the ciphersuites supported by the endpoint, where TLS is the protocol name, RSA is the algorithm that will be used for the key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA is the hash function to be used for message authentication. This is an example of a ServerHello message response to endpoint: Version 3,1 ServerRandom[32] SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58 b1b941e6b0c044acb6820a77 Use Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA Compression Algorithm: NONE In the above example, the ServerHello message includes: Version Number. The server sends the highest version number supported by both sides. This is the lower of: the highest version number the server supports and the version sent in the EndpointHello message. Randomly Generated Data. ServerRandom[32], the Random Value, is a 4-byte number of the server s date and time plus a 28-byte randomly d number that will be ultimately used with the endpoint random value

6 to a master secret from which the encryption keys will be derived. Session Identification (if any). This can be one of three choices. o o o New session ID The endpoint did not indicate a session to resume so a new ID is d. A new session ID is also d when the endpoint indicates a session to resume but the server can t or won t resume that session. This latter case also results in a new session ID. Resumed Session ID The id is the same as indicated in the endpoint hello. The endpoint indicated a session ID to resume and the server is willing to resume that session. Null this is a new session, but the server is not willing to resume it at a later time so no ID is returned. Ciphersuite. The server will choose the strongest cipher that both endpoint and server support, in this case the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. If there are no ciphersuites that both parties support, the session is ended with a handshake failure alert. Compression Algorithm. Specifies the compression algorithm to use (none currently supported). 6. IoTAS Ciphersuites SSL/TLS ciphersuites seem to be a good idea from the standpoint of flexibility and backward compatibility. If the endpoint proposes a state-of-the-art ciphersuite during the initial handshake, the server will select it as long as it is also supported by the server. If the endpoint proposes a not so recent ciphersuite, again the server will choose it if both support it. This endpoint-centered negotiation handshake within SSL/TLS, however, is a potential security risk since it may allow potential protocol downgrade attacks. Allowing an attacker to negotiate a lower version of SSL/TLS in order to exploit vulnerabilities is not exactly what designers had in mind, but it is possible. Such is the risk of attempting to support all-around or do-it-all protocols. There are so many degrees of liberty in the process that a weak link is exposed eventually. Endpoint App/Sensor IoTAS Cipher Suite IoTAS Library IoTAS Endpoint Public/Private Network IoTAS Server IoTAS Cipher Suite Figure 4. The IoTAS CipherSuite Core within IoTAS. App Server Public/Private VM/Physical Server In contrast, IoTAS does not have a negotiation phase during the initial handshake. Instead, IoTAS features a pre-embedded ciphersuite (at install time). Therefore, protocol downgrade attacks are impossible in IoTAS. Figure 4 above shows a high-level view of the IoTAS CipherSuite core and where it sits within the IoTAS middleware application and the original IoT application running on both endpoint and server. 7. Disadvantages of SSL/TLS SSL/TLS has grown to become a robust, flexible protocol for secure communications. However, this flexibility has also come with a high price tag. For instance, allowing anonymous endpoints 6 to negotiate a secure HTTPS connection by default over port 443 is certainly flexible, but it has also become a potential target for distributed denial of service (DDoS) attacks. Also, the negotiation of the ciphersuite itself exposes a latent vulnerability. Moreover, allowing SSL/TLS messages to be sent as readable text provides flexibility, but it is less secure than a binary protocol since it hints a potential attacker about the actual SSL/TLS settings and options used, allowing potential man-in-the-middle attacks to replicate similar setups. All of these design tradeoffs in SSL/TLS create vast opportunities for attackers to capitalize and exploit. On the other hand, it should be stated that some of the operational flaws in SSL/TLS are not only in the protocol itself, but in the default settings used by most servers. However, enforcing the use of safer configuration options in SSL/TLS, and keeping these synchronized across all exposed servers and data centers can be unfeasible. In contrast, IoTAS provides a simple deployment model where optimal settings are preconfigured to deliver maximum throughput, security, and session performance. 7.1 SSL/TLS Record Size and Buffer Latency SSL/TLS streams are sent by records, each consisting of a record header and a record body. The header encodes the type, one of: Handshake Change Cipher Spec Alert Data Figure 5 below shows the format of an SSL/TLS record. It consists of the content type, version, length, data or payload, and the MAC authentication code plus any padding if needed. Figure 5. Format of an SSL/TLS record. The size of SSL/TLS records can have a significant impact on the page load time. In fact, in the worst case, which unfortunately is more common than not on the web today, it can delay processing of received data by up to several roundtrips. On IoT networks, this translates to hundreds of milliseconds of unnecessary latency. As previously mentioned, each TLS connection begins with a handshake where the peers negotiate the ciphersuite, establish the session keys for the encrypted session, and authenticate their identities. With HTTPS, typically only the server s identity is authenticated e.g. is this really my bank? Once these steps are complete, the application data can begin to be transferred securely between endpoint and server. This is where data integrity and record size play a crucial role since they affect latency and performance Packing/Unpacking SSL/TLS Records Before the application data is encrypted, it is divided into smaller chunks of up to 16KB in size and each of the resulting pieces is signed with a message authentication code (MAC). The resulting data chunk is then encrypted, and the MAC, plus additional protocol metadata forms the SSL/TLS record, which is then forwarded to the peer. Figure 6 below depicts this process.

7 Figure 6. Packing an SSL/TLS record. Upon receipt, the receiver reverses the sequence. First, the bytes are aggregated until one or more complete records are in the buffer (each record specifies its length in the header). Once the entire record is available, the payload is decrypted, and the MAC is computed from the decrypted data and verified against the MAC contained in the record. If the two hashes match, data integrity is assured, and SSL/TLS finally releases the data to the application above it Head-of-line blocking and resulting latency SSL/TLS runs over TCP, and TCP as a reliable protocol promises in-order delivery of all transferred packets. As a result, TCP may suffer from head-of-line (HOL) blocking where a lost packet may hold all other received packets in the buffer until that packet is successfully retransmitted otherwise, the packets would be delivered out of order! This is a well-known tradeoff for any protocol that runs on top of a reliable transport protocol like TCP. However, in case of SSL/TLS, there is an extra layer of buffering due to the integrity checks. Once TCP delivers the packets to the SSL/TLS layer above it, it must first accumulate the entire record, verify its MAC checksum, and only then, the data can be released to the application above it. As a result, if the server emits data in 16KB record chunks, then the receiver must also read data in 16KB chunks at a time. Figure 7 below showcases this scenario. Figure 7. Unpacking an SSL/TLS record. In other words, even if the receiver has 15KB of the record in the buffer and is waiting for the last packet to complete the 16KB record, the application cannot read it until the entire record is received and the MAC is verified there lies the latency problem. If any packet is lost, it will take at least an additional roundtrip to retransmit it. Similarly, if the record happens to exceed the current TCP congestion window, then it will take a minimum of two roundtrip times (RTT) before the application can process the data. 8. Attacks and Exploits to SSL/TLS There have been several known attacks and exploits to SSL/TLS over the years. Some hijack the SSL/TLS handshake. Others attempt to exploit potential backdoors left by improper SSL/TLS installations. Others target the public cryptography used for key exchange, the weakest link in the protocol. Such was the well publicized attacks on the RC4 stream cipher. The next section provides a technical discussion of that attack. 8.1 RC4 in SSL/TLS As previously discussed, SSL/TLS does not rely on a single cryptographic primitive. Instead when a new SSL/TLS session is 7 established, both parties negotiate a ciphersuite. To agree on a common ciphersuite, the SSL/TLS endpoint sends a list of all ciphersuites it supports, and the server chooses one of them from the list, usually the first one which is also supported by the endpoint. The RC4 stream cipher is one of the possible choices for the encryption method, and it was also wildly supported and used. Compared to many other encryption methods, RC4 is very fast in software, very easy to implement, and also very efficient because it does not require any padding as block ciphers do RC4 in Wi-Fi networks A stream cipher should take a key, and transform this key into a pseudo-random byte sequence chosen from a uniform distribution. However, RC4 has a serious weakness here. For example, RC4 is also used in the famous WEP protocol, to protect Wi-Fi networks. Here, many similar RC4 keys are used that differ only in the first 3 bytes. These 3 bytes of the key are also used as an initialization vector for the cipher, and are transmitted unencrypted in the clear along with the encrypted packet. The remaining bytes of the key are shared among all packets, but should only be known to the operator of the network. What has been shown for WEP is that an attacker, who knows the first 3 bytes of the key, and also has access to some bytes of the key stream, can predict the next bytes of the key. The probability for predicting a single byte correctly is only slightly above a random guess, but repeating the procedure for many packets (like 10,000 or so) will reveal the secret key that protects the network with almost 100% probability. In a nutshell, if part of the RC4 key and some bytes of the keystream are known, then the remaining part of the key can be predicted better than just guessing RC4 in SSL/TLS For SSL/TLS, the situation is entirely different. Here, a new key is chosen almost randomly for every new connection and no parts of the key are shown to an attacker. As a result, the methods used to attack RC4 in WEP cannot be applied for SSL/TLS connections. However, there are more problems in RC4. Even if a key for RC4 is randomly chosen, the RC4 keystream has some biases. For example the second byte of output will be 0 with a probability of more than 1/256. What has recently been discovered is that much more of such biases exist. If a plaintext is transmitted over SSL/TLS, one gets a small hint about the plaintext. If the same plaintext is transmitted over and over again using TLS with RC4 encryption, one can recover the first bytes of the plaintext using these biases in the keystream d by RC4. No assumptions about other plaintext or keystream bytes must be made, and no knowledge of parts of the key is required. Also this works independently of the implementation, because it does not require any timings or similar side channels from the implementation Consequences of the RC4 attack The number of sessions required depends on how much is known about the plaintext, and what should be recovered. A full plaintext can be recovered using 2 30 sessions. If only a single byte needs to be recovered, about 2 24 sessions might be sufficient, depending on the position of the byte within the plaintext. If only two plaintexts need to be distinguished, then less than 2 24 sessions might suffice to break the RC4 key and obtain the plaintext Countermeasures of the RC4 attack How to counter this attack? One of the best workarounds is to simply disable RC4 support on either endpoint or server. As long as both endpoint and server still share another common ciphersuite, the secure session will be established properly. Alternatively, both the endpoint and server can be patched to send empty application layer records, until the first 256 or 512 bytes of RC4 output has

8 been used. Currently, the attack works best with the first bytes of RC4 output, but works less effectively with subsequent bytes. 9. IoTAS Secure Storage Overview IoTAS provides secure remote storage to any trusted endpoint by allowing seamless real-time encryption and optimization to any document sent to the server. The IoTAS secure storage library, which sits at the application layer, interacts with the IoTAS transport protocol to provide this essential feature. In a nutshell, IoTAS secure storage brings the following additional benefits to IoT applications already protected by the IoTAS protocol: Seamless file encryption. Optional data optimization. Single or shared remote access. Symmetric encryption of data. Vault-less Key Management System (KMS). Public key or Elliptic curve cryptography (ECC). Reduced metadata footprint within secured data. IoTAS allows users to safeguard data using advanced encryption with real-time data optimization. Secured data can be given access to a single endpoint, or shared access to multiple endpoints, including the local or remote storage facility, if needed. Figure 8 shows the system architecture for the IoTAS secure storage module. When data is to be protected, IoTAS creates a unique 256-bit or longer key (the per-file key), which is then used by the cipher to encrypt the file contents. The encrypted document also contains a randomly d file name (UUID) that can be stored locally, or on third party cloud storage services such as Google docs, Amazon S3, or Windows Azure. Figure 8. IoTAS Secure Storage System Architecture. The per-file key is encrypted with the data owner s public key. The encrypted per-file key and its encryption class are then wrapped with a NIST AES key wrapping, as per RFC The wrapped per-file key is then stored in the document s metadata. 9.1 Elliptic Curve vs. Public Key Mode IoTAS uses either public key cryptography, or elliptic curve cryptography (ECC) to allow shared view access among users. ECC is preferred as it offers the same or better level of security as public key cryptography, but using keys of smaller size. Hence, ECC does a much better job at optimizing the document metadata. 10. CONCLUSIONS SSL/TLS is the defacto standard for secure communications over the web. The protocol, however, has several shortcomings when it comes to creating secure sessions for data intensive, time-critical applications and, in particular, IoT. For instance, certain distributed applications within IoT must deliver data quickly and securely to their peers over high-speed networks. The one size fits all design of SSL/TLS simply does not scale up well in these scenarios. In addition, the flexibility and openness of SSL/TLS have also made it an easy target for certain vulnerability exploits within the protocol and the various algorithms supported in its ciphersuites. These exploits are a testament to the fact that the security of any system is only as good as the security of its weakest link. For SSL/TLS, or any other transport layer secure protocol, the weakest link is the key exchange. In order to address these challenges, IoTAS proposes a lighter, more efficient, pre-embedded ciphersuite that uses a pre-shared seed library for a stronger, more robust, key exchange. This makes it virtually impossible for potential man-inthe-middle attacks to compromise the secure session. IoTAS also features an advanced state-of-the-art stream-based cipher with optional data optimization, for a much faster, lower latency, secure session. IoTAS is capable of transcending the transport layer by allowing single or multiple access to secure documents on remote storage. Finally, IoTAS is ready to tackle the internet-of-things paradigm more effectively than SSL/TLS, especially as increasingly more connected devices require secure, real-time access, from anywhere at any time. 11. REFERENCES [1] Paris, L.; Mackey, M.; Seeded Cryptography and Compression for Data Transport and Storage. U.S. Provisional Patent. Seattle, WA [2] Paris, L.; Mackey, M.; Single-pass data compression and encryption. U.S. Patent 8,886,926. Washington, DC [3] Paris, L., Mackey, M.; Seeding of a workspace to optimize codec operations. U.S. Patent 8,804,814. Washington, DC [4] Paris, L.; High-speed data compression based on set associative cache mapping techniques. U.S. Patent 8,085,171. Washington, DC [5] Paris, L.; Inside Centri s IoTAS Compression Technology - CMC: Paving the way for real-time data acceleration. Mobile World Congress, [6] Wagner, D.; Schneier, B.; Analysis of the SSL 3.0 Protocol. The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press. pp [7] Rescorla, E; SSL and TLS: Designing and Building Secure Systems. Addison-Wesley. ISBN

9 About CENTRI CENTRI provides advanced security for the Internet of Things. Our technology helps organizations secure what matters most in IoT their data. CENTRI reduces the risk of data theft and loss of equipment command by establishing trusted devices and advanced encryption technology while retaining complete visibility to all activity. CENTRI maximizes IoT device uptime and protects the data in transit, at rest and on the endpoint. For more information visit centritechnology.com. CENTRI is a trademark of CENTRI Technology Inc. in the U.S. All other product and company names herein may be trademarks of their respective owners. centritechnology.com /centritech /centritechnology /company/centri-technology CENTRI Technology 701 5th Ave, Suite 550, Seattle, WA Main: Fax: sales@centritechnology.com Updated September