Test Results

About us

 Strong Encryption with RTC remote functions
Total posts: 1
 Author Strong Encryption with RTC remote functions
Danijel Tkalcec [RTC]

23.01.2007 20:22:47
Registered user
RtcClientModule and RtcServerModule support built-in strong encryption. This means that automatic strong encryption is provided for all RTC Remote Functions. By defining the encryption key size for the RtcServerModule component which uses a group of Remote Functions, all communication will be done using strong encryption for any client which requests encryption (simply by setting the EncryptionKey parameter on your RtcClientModule component).

Encryption states are session-persistent, while all handshaking between clients and the server (to start, reset or resume encryption) is done “under the hood” by the RtcClientModule and RtcServerModule components.

So, using the same connection, clients can request files from DataProvider components, call remote functions from different ServerModule components using sending plain data or data encrypted with built-in strong encryption.

Here’s a description of handshaking done “under the hood” when using built-in encryption:
1. Client generates a random Key:C1 and random number:A,
    then sends Key:C1+number:A to the Server,
    encrypted with SecureKey

2. Server checks number:A and generates a random Key:S1,
    then sends Key:S1+number:A back,
    encrypted with Key:C1

3. Client generates a random Key:C2 and random number:B,
    then sends Key:C2+number:B to the Server,
    encrypted with Key:S1

4. Server checks number:B and generates a random Key:S2,
    then sends Key:S2+number:B back,
    encrypted with Key:C2+Key:S1

5. Client generates Data:X and a random number:X,
    then sends Data:X+number:X to the Server,
    encrypted with Key:S2+Key:C1

6. Server checks number:X, executes Data:X and prepares Result:X,
    then sends Result:X+number:X back,
    encrypted with Key:C2+Key:S1

7. Client checks received number:X with generated number:X,
    then calls events to use the Result:X

8. Steps 5 to 7 are repeated as long as there is data waiting
    to be sent, until session expires or server reboots.

9. If session expires, key changes or server reboots,
   steps 1 to 5 are executed again to generate new keys.

To set encryption parameters, RtcServerModule and RtcClientModule components have the “EncryptionKey”, “ForceEncryption” and “SecureKey” properties, using which you define how long the Encryption Keys should be, whether your component needs to enforce encryption and which secure key you want to use for that component.

The longer the encryption key and the secure key, the stronger encryption. For each new session started, a separate set of 4 keys will be random generated (2 by client and 2 by server). Encryption keys are only sent on initialization, or when session expires while it was idle for longer, while the SecureKey is never sent (it is only used locally to encrypt and decrypt the first client key).

If you chose a high value for your ServerModule’s AutoSessionsLive time and have good connectivity between client and server (connections don’t usually drop in the middle of data transfer), your random generated keys could stay valid for a long time, so that your clients won’t even notice the small overhead used by encryption.

Because the keys are changing with every byte sent or received, you don’t have to bother with changing the key manually. And if your client is idle for longer time period, any request sent from client after its idle time will trigger automatic key renewal.

BUT ... there is one important difference between the proprietary built-in RTC encryption and standard SSL encryption. While everything you send or receive will be encrypted when you use standard SSL encryption, only DATA (content body) will be encrypted with RTC encryption. HTTP headers containing the requested URL and users Session ID will NOT be encrypted when using only built-in RTC encryption and can thus be read and/or modified by any Proxy through which the client is connecting to the Server.

Naturally, intercepting data sent and received using RTC encryption would not be easy. For one, it can't be done simply by using some standard Proxy. A special Proxy would need to be written for that purpose by using the same encryption/decryption algorithms and same protocols as used in the RTC SDK. Second, that special Proxy would need to be placed in-between your Server and your Clients so that your Clients would connect to/through that special Proxy without knowing it. And third, that special Proxy would need to know your SecureKey, or be able to somehow guess your SecureKey in order to decipher your data. Without knowing or guessing the SecureKey, or without having someone capable of writing that special Proxy and someone in a position to place that special Proxy in-between your Client(s) and your Server to silently and transparently process all incoming and outgoing data, a third-party will not be able to compromise your communication and you can safely use built-in RTC encryption.

In other words, even though RTC encryption is quite safe, it can be compromised (provided someone has sufficient resources to do so) and should therefor NOT be seen as a replacement for standard SSL encryption. This is why anyone who is working with sensitive data and needs maximum security and privacy should use SSL encryption.