Security - Details

CrossLoop has been designed and implemented with security in mind.This includes all aspects of the website, the server and the clients. The purpose of this section is to cover the CrossLoop security model.

Website

The CrossLoop website provides HTML pages which describe the product, tells how it works, allow you to track your sessions, be able to promote yourself and your profile, contact helpers, address frequently asked questions and give you information about the company and how to contact us.

When you login to the site, we use SSL to ensure that your login credentials are secured.

Client Download

When you download the client application from the CrossLoop website using the "FREE DOWNLOAD" button you should see an Internet Explorer (or FireFox equivalent, etc.) Security Warning -

It is important to confirm that the download is from the crossloop.com domain. If the crossloopsetup.exe is not from the crossloop.com domain, your access to the CrossLoop website has been compromised. When you select "Run" you should see an Internet Explorer (or FireFox equivalent, etc.) second Security Warning -

The crossloopsetup.exe is a signed executable module for download. The display of CrossLoop, Inc. as the Publisher verifies that we are the signers of that code. If you do not see this message, your access to the CrossLoop website has been compromised. The Publisher: CrossLoop,Inc. is a link which you can click to view the publisher's digital signature.

You should be able to confirm that, "This digital signature is OK." Clicking on "View Certificate" you will see the following Certification Information -

Confirming the validity of the digital signature on the downloaded executable module is important because it verifies the origin of digital content and the fact that it hasn't changed since it was signed. If you trust the source (CrossLoop, Inc.), then you can trust the application because it comes from a verified source.

After the code-signed file (crossloopsetup.exe) is downloaded from the website, the browser extracts the certificate from the file, and checks an internal list of certificate authorities (CAs) and their public keys to verify the signature in the certificate. If the signed software is tampered with in any way, the digital signature will break and alert you that the code has been altered and is not trustworthy.

Client Access Code

Unlike remote control software (GoToMyPC, pcAnywhere, LogMeIn, etc.) which enable you to remotely control an unattended computer, CrossLoop requires the presence of a person at both the Share and Access computers for a connection to be made. This is a key element of the CrossLoop security model.

The Share computer which shares control with the Access computer must have a person who gives the Access Code to the person on the Access computer. Once the rendezvous is completed between the Share and Access computers, the Share is asked to allow or deny a session with the identified Access computer.

When the person at the Share computer has clicked the "Connect" button and is waiting for the person at Access computer, the Share computer will timeout in 2 minutes in the absence of a Access computer connection. Thus, it is not possible to leave a Share computer unattended waiting for a Access computer. A person must be present on both computers in order to initiate a CrossLoop screen sharing session. When the person at the Share computer clicks "Connect" a timer is shown in the dialog which counts down from 2:00 minutes. A disconnect is automatically made when the timer reaches 0:00.

When the CrossLoop client is executed and the Share tab is selected, a randomly generated 12-digit Access Code is displayed on the client. This 12-digit Access Code is generated on the client and is a product of several variables, examples of which could include: the current system time; the contents of uninitialized memory; the user / computer name; the amount of disk free space on the client computer, etc. The CrossLoop server is not involved in the generation of this code and does not have any access to the 12-digit Access Code or the variables used by the Share to generate the Access Code.

The Access Code on the Share is passed out of band to the person on the Access computer. Typically this is done over a telephone, using VoIP (Skype, Vonage, etc.), or with a secure chat / instant messaging program. Each time that the CrossLoop client is executed, a new Access Code is generated for the Share. Since there is no single repeatable Access Code for a Share, there must be communication between the persons at the Share and Access computer to exchange the new Access Code.

The 12-digit Access Code is used as the input to a one-way hashing algorithm (MD5) to produce a 128-bit symmetric key for the Blowfish encryption. Blowfish is used to encrypt all communication between the Share and Access computers. The CrossLoop server never has access to the Blowfish encryption key.

Client User Experience

The user experience for the CrossLoop clients has been designed to promote security by facilitating a disconnect and also to make the person on the Share computer aware that their screen is being viewed by the person on the Access computer.

At any time the person on the Share computer can hit "Disconnect" to end a session
There is no "Confirm" on the disconnect so that it will take place immediately
The Share client dialog is always on top so that the person on the Share computer is aware that the computer is being watched
During a time of inactivity, or if minimized, the dialog is periodically brought back to the top

Client Rendezvous

The CrossLoop server is used as a rendezvous point to connect the Share and Access parties. This rendezvous is accomplished by matching Session IDs between the Share and Access computer. The 32-bit Session ID used in the rendezvous is generated by obfuscating the 128-bit symmetric key generated from the one-way hash of the Access Code. When a match is found between Share and Access Session IDs, a known plaintext message is encrypted with Blowfish at the Share using its 128-bit symmetric encryption key and sent to the Access computer. The Access computer decrypts the encrypted message with Blowfish using its 128-bit symmetric key and will only be allowed to continue if the decrypted message matches the known plaintext message.

Once the rendezvous for the Share and Access parties is completed CrossLoop attempts a direct peer-to-peer (P2P) connection between the Share and Access computers. This is usually possible and is successful in about 85% of the connections. If not, CrossLoop relays all of the messages between the Share and Access computers through the CrossLoop relay server. CrossLoop sometimes fails to make P2P connections when a poorly behaved router is involved in the connection, or when UDP packets are blocked.

Blowfish Encryption

All of the data transferred between the Share and Access computers is encrypted / decrypted using the Blowfish symmetric encryption algorithm developed by Bruce Schneier (http://www.schneier.com/). Blowfish is a variable-length key block cipher. The key length used by CrossLoop is 128-bits and the algorithm is a 64-bit block cipher.

Blowfish is a block-encryption algorithm designed to be fast (it encrypts data on large 32-bit microprocessors at a rate of 26 clock cycles per byte), compact (it can run in less than 5K of memory), simple (the only operations it uses are addition, XOR, and table lookup on 32-bit operands), secure (Blowfish's key length is variable and can be as long as 448 bits), and robust (unlike DES, Blowfish's security is not diminished by simple programming errors).

The Blowfish block-cipher algorithm, which encrypts data one 64-bit block at a time, is divided into key-expansion and a data-encryption parts. Key expansion converts a key of at most 448 bits into several subkey arrays totaling 4168 bytes. Data encryption consists of a simple function iterated 16 times. Each iteration, called a "round," consists of a key-dependent permutation and a key- and data-dependent substitution.

Summary

Security is extremely important to us at CrossLoop. A key part of our security model is that we require the presence of a person at both the Share and Access computers in order to conduct a screen sharing session. A Share computer cannot be remotely controlled with CrossLoop unless you are present at your Share computer and accept a connection.

We have endeavored in the design of CrossLoop to provide you with Simple Secure Screen Sharing and thereby earn your trust.

Frequently Asked Questions (FAQs)

I like CrossLoop and want to use it again, if only I were sure that it's a safe application.

You have a good concern and apart from the fact that our business and existence depends on trust and security of our software, we have prepared this section of our website to describe our security.

What information does CrossLoop track about my sessions?

The CrossLoop Share and Access clients are identified by a "Name". This name is generated automatically from your user name and computer name, e.g. "TOMR on TOMS-EMACH2". However, this field is editable and you are free to change your name to anything you wish. This "Name" is sent in clear text to the CrossLoop server during the rendezvous phase of the connection. In addition to the name the client also sends information about the version of CrossLoop which the client is running. This information includes the software version and build number. The reason for sending CrossLoop version information is to verify that we are able to connect the Share and Access clients.

After a connection is established and a session is created between the Share and Access computers, CrossLoop tracks the length of the session and the number of bytes sent between the computers. Periodically, both the Share and Access computers send information about the number of bytes sent/received to the CrossLoop server. This data is used for performance tuning and optimization of the CrossLoop services. CrossLoop also tracks the type of connection, relay or P2P.

In no event does the CrossLoop server have access to the encrypted screens which are shared between the Share and Access computers.

At the end of each session the local registry on the client is updated with session information, including: type of session (Share or Access), length of session, and a rating value if the session was rated. This information is only collected on the client and can be displayed on the client by accessing the "Usage Statistics" menu item. The purpose of this information is to allow you to see your accumulated usage of CrossLoop.

How do I know that CrossLoop is not a CIA front and is secretly logging/storing all of the traffic that is passed through the encrypted tunnel used by CrossLoop?

Perhaps the only way to convince yourself would be to use a protocol analyzer, or "packet sniffer" and watch the packets on the wire sent and received by CrossLoop. You would also need a tool to monitor your disks for changes to see if CrossLoop was logging/storing information. We only log information about your sessions which we have described in this security section.

In no event do the CrossLoop clients log or store any of the screen sharing traffic passed between the Share and Access computers.

Since CrossLoop is not open source, there is no way for anyone to prove that there is no secret back-door in the code... or am I missing something?

CrossLoop is a shell program which uses fork and exec to invoke a VNC (Virtual Network Computing) program. The Windows version of CrossLoop currently uses the TightVNC plug-in program, a free GPL-licensed, remote control software package derived from the popular VNC software. The binaries of TightVNC are unmodified and are included in the CrossLoop installation software. The CrossLoop website has a complete description of the interface between CrossLoop and VNC.

There are no back-doors in the CrossLoop client or server code.

Our network falls under HIPAA regulations and therefore we must control unauthorized access to and from our network. Not to be Draconian about this but we do have some non-IT “experts” in our organization that attempt to install programs on our network for remote control. Your product looks very interesting for its intended market. How can we block its usage on our network? Will blocking your server IP addresses so that the session negotiation cannot occur be adequate? Are there specific ports that crossloop uses that can be blocked?

Blocking our server IP address would be an effective way of stopping the usage of CrossLoop on your network. Our client software must be able to contact the CrossLoop server using HTTP through port 80 during the rendezvous phase of our connection.

We certainly understand why your IT department would be concerned about unauthorized access to and from your network. However, CrossLoop cannot be operated remotely because it requires the presence of a person at both the Share and Access computers to make a connection. Presumably the person at the Share computer inside your network would be authorized. This person would need to allow a connection to be made from the Access computer.

I have known 128-bit encryption to be cracked for over a year. What is different about "Blowfish" encryption that makes it "more secure"?

We are aware that the 64-bit block size of Blowfish is considered short. This weakness has been exposed when encrypting more than 2**32 data blocks because it begins to leak information about the plaintext. Since our sessions involve considerably less than 33.6 Gigabyte data blocks (33.6 Gigabytes = 2**32 * 64-bit / 8-bit/byte) we do not regard this as a security risk for our users. We generate a new Access Code and produce a new symmetric key each time our application is run. We feel that the advantage of the extremely fast Blowfish algorithm and the credibility of Bruce Schneier have made Blowfish an excellent choice for our crypto.

Why does the program open 3 different ports in my firewall? As far as I knew, a program like this only requires 1 port.

We open additional UDP ports in our attempt to do P2P communication between Share and Access parties to avoid relaying through our server. If you only want port 80 to be accessed then do a relay connection by holding down the ALT key when you press "Connect". Our port 80 access tunnels inside of HTTP POSTs.

How do you ensure the data packets between the client and the Share are not intercepted?

Our encryption is done at the endpoints and is not exposed in plaintext anywhere during a session between the Share and Access computers. During relay connections our server has no access to the Blowfish encryption key. A man in the middle attack would not be possible without knowledge of the Blowfish encryption key.

Does this program have protection against TCP flood and Denial of Service (DOS) attacks?

Since we don't require open TCP ports that anyone on the net can connect to (i.e. open to SYN flood attacks), we're not vulnerable. In fact we provide extra protection for the Share which is executing WinVNC because we allow only loopback (localhost on 127.0.0.1) connections. It is impossible for an outside computer to connect directly to WinVNC.

Does your program have a method that I can use to prevent it from running at certain times or under certain circumstances, or do I have to get a third party program to do that?

Our program cannot run unattended. In other words, it will only run when you invoke it. If you push the "Connect" button as a Share party we time out after 2 minutes. If you are running something that you do not wish anyone connecting to your computer to see … do not run the Share, or if it is loaded, do not Connect.

How do you ensure only the invited client can connect?

The invited client must receive the Access Code from the Share via some out of band technique, e.g. over the telephone. The Share cannot run unattended and we purposely timeout the Share after two minutes. We expect there to be human conversation between the Access party and the Share party. When the Access party enters the Access Code received from the Share there is an Allow/Deny screen displayed at the Share. The Share must allow the connection to proceed before the Access party has access to the screen of the Share party.

We hash the symmetric key generated from the Access Code to produce a 32-bit session ID. This session ID is used for our rendezvous between the Share and Access party. It is a necessary condition but not sufficient condition to allow the invited client to connect because we encrypt a known message with the full 128-bit encryption key at the Access party and decrypt it at the Share end. There can only be a match if the Share party and Access party have the same 128-bit encryption key.

I was just recently introduced to CrossLoop and gave it a test drive while assisting a customer with software issues - it worked GREAT!! However, when I approached our IT department about this fantastic little application, they were not as enthused as I was; they stated that any VNC product created security issues by opening a non-secure tunnel into our servers. Is this actually the case?

IT managers generally regard any VNC product to be a security risk because they require an open port on the server and communicate with unencrypted data between the client and the server. Typical VNC products (RealVNC, TightVNC, UltraVNC, etc.) all have the security problem in that they require an open port on the internet to operate as a host (running WinVNC or the equivalent). Furthermore, you must forward the VNC port requests to your computer from your firewall. This is a huge security risk, which is coupled with the absence of built-in encryption and poor authentication. From this perspective, the IT managers are correct about the security risks.

The CrossLoop Solution:

CrossLoop provides a secure wrapper around VNC operation.
VNC is configured so that it will only accept connections from localhost (127.0.0.1). This means that there are no open ports on to the Internet or LAN and that VNC will only accept connections from the computer on which it is hosted. There is no requirement to modify your firewall to forward VNC port requests to your computer. Our CrossLoop software acts as a proxy running on a localhost connection with VNC. CrossLoop has no inbound open ports and performs the rendezvous between the Share and Access clients by means of an HTTP POST to our server.
All communication between the VNCViewer (CrossLoop Access) and the WinVNC server (CrossLoop Share) are encrypted using Blowfish with a 128-bit encryption key. This communication includes both the authentication of the VNC connection as well as all of the screen/mouse/keyboard updates.
Unlike the normal VNC server, the CrossLoop Share cannot be operated remotely and does not support unattended sessions. It requires the presence of a person on the Share computer to accept the CrossLoop session request from the person doing the CrossLoop Access.
Each time CrossLoop is executed a unique 12-digit Access Code is generated for the session. This Access Code is hashed to generate the 128-bit encryption key used by Blowfish. Thus, each CrossLoop session has a different encryption key. This is unlike VNC in which the same authentication password is used for each connection.
Because there are no open ports on the client computers, CrossLoop is protected from SYN floods or other forms of DOS attacks. This would, for example, be possible with a traditional VNC server which opens a port through the firewall and sits there listening on a port. Since we don't require open TCP ports that anyone on the net can connect to (i.e. open to SYN flood attacks), we're not vulnerable. We provide extra protection for the Share which is executing WinVNC because we allow only loopback (localhost on 127.0.0.1) connections. It is impossible for an outside computer to connect directly to WinVNC.

Please contact us at support@crossloop.com if you have any further questions about our security