Collaborator Security Information - Overview

I. Document Description

The purpose of this document is to provide an overview of the security components of the Collaborator application service, as well as some related architectural elements that may also impact security issues. This information is provided so that I.T. personnel may grasp the security related implications of using the Collaborator application within their own environments.

It is NOT intended to provide a detailed technical review or analysis of the Collaborator security components. For a detailed analysis, please refer to http://www.thoughtrealm.com/caruso_security.php. Additionally, there may be other documents that you may find relevant to this topic. Please refer to http://www.thoughtrealm.com/caruso/ for references to other documents and information.

II. What is Collaborator?

Collaborator is a hosted application that is accessed over the Internet, which allows users and small to medium sized teams to share project related data. The Collaborator application is made available to subscribers for a fee. The Collaborator technology is built using the Caruso application hosting architecture.

III. What is a "Hosted" Application?

A hosted application is a program that does not reside on your local machine, at least not completely, but has some portion of the application that is located on a remote server. With a "Local" application, the software resides completely on your system.

The primary benefit associated with hosted applications is that they can be offered as a service, instead of as a product. As a result, you simply pay a service fee to access a hosted application. This is in contrast to paying a full product price for a software product that you install locally.

There are numerous benefits to hosted applications, including access from anywhere that has an Internet connection, the fact that your data follows you anywhere you login, low I.T. requirements for end-users and their systems, resilient mission criticality through application and infrastructure outsourcing, as well as many other benefits.

Providing applications in a hosted model is a common goal for many of today's software companies, due to the many benefits derived from doing so, for both software companies and their customers.

IV. What is Caruso?

Caruso is an application hosting infrastructure or "platform", designed by TRA (ThoughtRealm Alliance). Caruso was designed to provide an application hosting framework that is secure, reliable, application oriented and user friendly.

In order to accomplish this, Caruso uses NO web components; such as, web servers (IIS, Apache, etc), web browsers (IE, Firefox, etc), web protocols (HTTP, etc), web transport security (SSL/TLS, etc), web presentation languages (HTML, CSS, etc) or web scripting environments (Java, ASP, PHP, etc). Instead, Caruso provides its own communication protocols, server software, Client software and scripting environments, in order to support hosting applications TCP/IP capable networks.

V. Why Caruso?

The purpose for creating Caruso is to provide a more appropriate application hosting solution than the web provides. The result is an application hosting architecture that has few to none of the weaknesses of the Web, especially regarding security vulnerabilities. Instead, Caruso provides a more efficient, secure and usable application hosting architecture than Web server based applications. Basically, Caruso throws the Web away and starts over with a simple Internet based architecture; meaning, a TCP/IP based transport that is unencumbered by the poorly kludged polyglot of the Web stack of technologies.

Most people, including many I.T. specialists, do not grasp the significance of the differences between the Web and the Internet, or the impact that the evolving Web technologies have had on network based (multitier) applications. The difference being that the Internet is a highly resilient network topology, developed quite some time ago; while what we know as the Web is simply a set of protocols and supporting services that run over the Internet, which were developed comparatively recently.

As the Web quickly grew in popularity in the 1990s, due to the ease by which the Web browsers allowed users to access documents and information, a rapid push within the software industry emerged with its goal to move end user applications into a Web browser based environment. The near-sightedness of this push completely ignored the fact that a Web browser is a HORRIBLE environment for running software applications. While some technologies have emerged to make the process almost workable, including an increase in supporting technologies within Web servers themselves, such as IIS and Apache, the fact remains that the Web was NEVER designed in its foundational efforts to support the concept of users, security, sessions, state, or any of the basic needs of a truly application-centric hosting environment.

As a result, the Web has become a dismal kludge, comprised of a mesh of numerous, complex technologies; none of which actually provide a better application environment for software developers, but have actually compounded the problem. Unfortunately, at the top of the list of missing necessary elements for software end-users has been the sacrifice of a commensurate security infrastructure. Today's Web compromises exist due to the failings of the underpinning designs of the Web itself. As a result, there is no real solution in sight. Not only does the Web fail horribly in so many areas for hosting applications, it ultimately has no foreseeable remedy for its failures.

While the modern zeitgeist may proselytize "Webifying" everything in sight in the software industry, unfortunately, software applications do not lend themselves well to this environment. Ultimately, the end-users pay the price and suffer the consequences, not only with poor security controls that are just getting worse, but also with a poor user interface, entrenched in browsers that provide great support for displaying documents, while providing terrible support for running applications.

The purpose for stating the obvious state of the Web with such starkness is to illuminate why the founders of TRA created a non-Web solution in an obviously Web-driven world. The founders of TRA began decrying the obvious future of Web based solutions in the late 1990s, while working on alternate technologies for replacing Web based hosting solutions that are more application-centric. The current status of the Web has clearly affirmed their initial concerns.

Caruso represents the fruit of over 10 years of research and multiple iterations of software approaches by the founders of TRA. The Collaborator product is the first in an upcoming line of applications that will be built with the Caruso architecture.

VI. Caruso architecture overview

Caruso exists of several elements that provide the Caruso application hosting framework. The majority of them can be categorized as follows:

• Application Routers
• Application Servers
• File Servers
• File Server Controllers
• Administrative Tools
• Client Software
• Communication Protocols
• Application Databases and Servers
• Customer Databases and Servers

Generally, the primary elements can be further grouped into Servers, Clients and data communication (protocols and processes). A Caruso application, such as the Collaborator, is composed of a number of application elements that reside on the Servers and the Client, which work together in order to service the end-user's application services.

The Caruso servers provide the necessary application hosting services that the application needs for providing the end-user services of the application. These include numerous points for maintaining state (client side, server side, UI elements, etc), perpetual sessions, native scripting support, native channel authentication and encryption, and a number of other hosted application needs.

The following is an overview of some of the key components of the Caruso architecture:

• Caruso Secure Channels
  Tantamount to the Caruso design is a security capable framework. In order to provide this, a "natively secure" and trustable channel architecture is incorporated as the foundation for ALL communications. By "natively secure", we mean you don't have to rely on some channel extension or add-on technology to make the channel secure, such as SSL/TLS. The Caruso secure channel pattern is used for all communications between the various software elements, including back-end administrative channels, as well as communications between the Client and Servers.
  
  This means that ALL INFORMATION is encrypted between the Client and the Servers, as well as between the various servers themselves and all support tools. With Caruso, there is NO SUCH THING as a clear or unencrypted communication. With the web's architecture, you can provide clear (HTTP) or secure (HTTPS) channels, by engineering your pages to require or not require SSL/TLS. That is NOT possible with Caruso. EVERY channel is encrypted within the Caruso framework.
  
  Additionally, because end-user identity is bound to the channel encryption between the server and the Client during channel "promotion", there is no such thing as an anonymous connection. The Caruso channel pattern requires the Client to promote the channel by binding the user identity to server-supplied random channel sequences algorithmically during session initiation. This promotion process produces random channel parameters that are bound to the user's identity for every connection. This results in a trusted, always available user authentication that a hosted application can rely on. This channel process occurs PRIOR to the application session being granted. The hosted application has full control and responsibility for governing this process, so different Caruso applications may use completely different verification techniques to identify and authenticate users.
  
  In contrast, with a web application, the application must provide its own user authentication functionality on top of the HTTP channel, AFTER the page is accessed and possibly over a clear (unencrypted connection). The impact of this approach is that it requires an application to constantly re-assert user or session identification (via browser ID, CGI parameters, POST variables, etc) across pseudo sessions for every page and page element browsed, as well as possibly for every data request made by the user. The result is a horrifically inefficient and cumbersome process that is rife with opportunities for application designers to mistakenly provide security vulnerabilities without even being aware of them.
  
  The Caruso channel architecture, on the other hand, provides native channel authentication and encryption that doesn't have to be re-acquired every time the user's system requests a piece of information. The impact of this is that the Caruso channel authentication process provides a much more efficient, more trustable identification and authentication solution. There are also several technical side-benefits to the Caruso channel pattern as well.
  
  One is due to the fact that the Caruso channel pattern incorporates persistent sessions natively. This is much more TCP/IP friendly than transient sessions as implemented by HTTP. For example, unknown to most I.T. specialists, to overcome some possible topological issues when starting a TCP/IP connection, most socket vendors (e.g. Windows, etc) implement a technique known as "TCP slow starts". Basically, this technique slowly grants bandwidth, in the form of socket window sizes, to a new TCP connection, so that a socket doesn't obtain access to the entire channel's bandwidth until after several packets. This prevents some inherent topological flaws in TCP/IP from unintentionally consuming all of the bandwidth of the network channel. With Caruso, this process only occurs once, when the session is first initiated. Afterwards, the socket communications can proceed with no related performance issues.
  
  HTTP, in contrast, is inherently stateless and transient, meaning it maintains no state information between requests and must reestablish a TCP/IP connection on almost every request for page data, sometimes for each image and section of page content, depending on how the web server is configured and page is designed. To support this, the web server requires the user or browser authentication to be re-asserted and the channel security re-negotiated for every request. This approach to stateless, transient sessions is inherently inefficient with TCP/IP. So, for example, with a web browser page load, "TCP slow starts" may occur for every request the browser makes to the various elements of a page, and usually (depending on numerous configuration issues) for every page. This can drastically reduce throughput, even on high throughput connections, especially in high latency or heavy server loading scenarios.
  
  Another benefit of the Caruso architecture is that it requires the user to provide two passwords, instead of just one. This mechanism increases the difficulty of password dictionary attacks, which are much more successful than they should be, due to the usage of common and weak keys. With Caruso, you would have to guess two passwords in the proper order and proper casing to execute a successful password dictionary attack.
  
  The last benefit we will discuss here provided by the Caruso channel pattern is that it requires no exchange of passwords. Only the user ID, which can be any alpha sequence, is exchanged in an encrypted form. The actual passwords are never exchanged in any form. This effectively defeats a web style phishing site attack, where a user's web browser is diverted to a false site in the hopes that they will submit their passwords so that they may be captured for some malevolent purpose. With Caruso, the passwords are never submitted during login; as a result, such an attack will not provide any desired benefits.
  
  In regards to the nature of the Caruso channel encryption itself, the channel employs two "state perpetuating" stream ciphers; one for outgoing data and one for incoming data. By "state perpetuating", it is meant that they do not reset their states when encrypting one message to the next; but instead, perpetuate their cipher states as a progressing set of channel parameters. These ciphers incorporate an industry standard symmetric block cipher in a feedback state; the output of which is randomized with the output of a 128-bit LFSR randomizer.
  
  Currently, the block cipher is implemented as a 16 round Blowfish cipher using 256-bit keys. The keys are determined algorithmically using inputs from random char sequences issued by the server coupled with functional decompositions of the two user passwords into multiple sets of key / IV sequences using additional ciphers, as well as hash values using a 256-bit variant of RIPE-MD. According to Bruce Schneier in, "Applied Cryptography, Second Edition", RIPE-MD is thought to be "highly resistant to cryptanalysis" [1]. The key sets are used to co-initialize the session's Client and server endpoints with value sets for the Blowfish ciphers and LFSR randomizers.
  
  The Caruso channel is not dependent upon any specific block cipher, so future cipher implementations may utilize a different block cipher, based on any number of criteria. However, Blowfish was chosen for the current implementation based on the following properties:
  
  
  1. It is "open" and unencumbered by patents or licensing requirements
  2. It has been around a long time and has been analyzed and scrutinized heavily. The results of which have demonstrated that the only known successful attack against 16 round Blowfish is a brute force attack. Given our key size, this should be quite sufficient for the foreseeable future.
  3. 3. Due to its 64 bit block size, it is very fast for 32 bit architectures. While it has a large initialization cost during session startup and promotion, once initialized, it progresses as a stream cipher very quickly. Due to the growing popularity of 64-bit machines, a 128-bit block cipher may be mandated in the future for performance reasons, such as Twofish.
  4. It supports up to 448-bit key sizes, which is very large for block ciphers.
  During sign-on, the Client / Server channel is initialized (statically promoted) using semi-private keys that may vary per server. They are considered semi-private, since they are shared by all connecting clients. These semi-private keys are encrypted in a file on the user's machine. Once an ID is submitted, the channel is re-initialized (dynamically promoted) using the user's actual keys and a random data sequence provided by the server, as well as server provided salting and stretching parameters. The client then resubmits the output of a challenge function using the recently initialized cipher states. If this output is verified successfully by the server, the user's identity is asserted with a high degree of confidence.
  
  At this point, once the user's ID is verified and the channel session is promoted to a trusted state, the channel encryption states then progress randomly, as a function of user interactions, as well as of cipher and randomizer feedback.
  
  Given the previously described process, the Caruso channel encryption has the following characteristics:
  
  
  1. Identity reliably determined without exchanging passwords.
  2. Successfully defeats MITM attacks. **
  3. Successfully defeats replay attacks. **
  4. Very fast encryption throughput.
  5. Uses "end-to-end" approach, so that encryption is provided at the application layer, instead of a lower layer, which defeats local or stack based MITM attacks. **
  6. Stream cipher requires knowledge of all derived initialization parameters for both startup phases, static and dynamic, as well as the entire preceding session history, in order to decrypt any single data block at any arbitrary point within the session. This effectively defeats using the results of a successful attack against one arbitrary block within the session to decrypt any other arbitrary block within the session.
  7. The 128-bit LFSR is incorporated to mask cipher output in order to defend against a number of attacks. Additionally, obscuring the output in this manner conceals any key leakage in the ciphertext. While leakage issues are typically only relevant over a large number of encrypted blocks, the randomizer minimizes the issue effectively.
  8. Intentional high level of fragility, so that any alteration of the stream results in a security failure. While this would not be appropriate for environments with frequent occurrences of packet loss, such as deep space communications, it is quite appropriate for the vast majority of networks.
  [** Assumes attacker does not have user's keys in hand]
  
  
• Client software
  The TRA Secure client software is able to connect to any Caruso hosted application, such as the Collaborator. It is a hybrid of "thin" and "smart" client architectures that is application agnostic, in that it is able to run any Caruso application. It simply provides a services for Client functionality that can accessed by any authorized Caruso hosted application.
  
  The Client is a small set of software services that install locally on the end-user's machine. It has a small footprint with very minimal system impact from installation. Once installed, it is generally self updating with only a few key presses for user approval during updates.
  
  Before describing the Client's communication processes, it is worth noting that all Client connections are OUTBOUND. Caruso NEVER exposes an inbound TCP/IP connection on the user's machine. Therefore, there are no open ports that can be attacked as a result of running the Caruso Client software. All application communications occur over one outbound initiated, persistent TCP/IP connection; this is with the exception of file transfers that will be described later, which simply use a transient outbound connection to a Caruso File Server for each batch transfer.
  
  When the Client software connects to a server, a secure session is established as previously described. This startup process typically requires just two TCP/IP connections and the exchange of a few packets. In contrast, web connections, especially over SSL/TLS, may require some number of TCP/IP connections and a large number of packet exchanges. In comparison, the Caruso session startup is vastly more efficient than a comparable web process and transfers much less data. The same comparison applies to the remaining Caruso session in general, in that the Caruso session typically requires a small fraction of the packets and data that would be required by a comparable web based session. This is due to Caruso's application oriented protocols that were designed specifically to support applications; as opposed to HTTP, which was originally designed to support the exchange of documents. As a result, a particular network infrastructure is typically capable of handling significantly more Caruso traffic than comparable Web traffic.
  
  When the Client session starts, it first contacts a Caruso Router. The Router is a load balancing service that re-directs the Client to an appropriate application server for the requested application service. While doing so, the Router also generates a unique, random, time-based session ticket which is provided to the Client. Additionally, on the server back-end, the Router notifies the specified application server regarding the expected Client connection, while providing the same ticket information. This load balancing phase is very brief, requiring a single packet exchange between the Client and the Router.
  
  During the routing phase, the Router also confirms that the Client is using the correct version of the Client software to access the requested application service. If it is not, the Client is automatically redirected to an update application for distributing the appropriate Client version to the user.
  
  After the routing phase, the Client then connects to the application server as specified by the Router. While doing so, it provides the session ticket to the application server. Assuming that the ticket has not timed out, the application server initiates negotiation of a secure channel with the Client. Assuming that the Client's identity is approved, the secure channel is established. This phase requires just 3 packet exchanges between the Client and the server. The entire process from contacting the Router to establishing a secure channel with the application server requires only 8 packets. This channel is maintained for the life of the user's session and is not disconnected until the Client or server terminates the session.
  
  Once the secure channel is negotiated, the "application session" phase begins. At this point, based on the design of the application, the server may first synchronize some number of Client-side application elements with the Client. Then, the application start event is triggered on the server, which typically instructs the Client to display the initial User Interface elements of the application. In the case of Collaborator, this would be the main form.
  
  At this point, the Client's role is simply to present the user interface elements to the user as directed by the server, while responding to user interactions and informing the server as appropriate. However, in this mode, the Client is not just a dumb terminal or simple thin client, but rather it is provided with and executes Client side application elements, as well as the user's data as collected and distributed by the sever. As such, the session proceeds according to the design of the particular application the Client is running and how it supports the available Client input. This is similar to any event driven application, with the distinction being that, as a distributed application Client, parts of the application logic are executed locally and parts are executed remotely on the server. How this logic is segregated between the Client and the server is determined the developers of the particular application. When designed correctly, this process can be very quick, with the goal of appearing to operate at speeds similar to locally installed applications.
  
  Ultimately, the session mode ends when the application session is terminated, by either the server or the user; after which, the secure channel is disconnected.
  
  
• Caruso Application Elements
  A Caruso application consists of collections of scripts and data objects (images, etc). Scripts are classed according to various roles (Client, Server, etc), as well as how they related to specific server and session life-cycle events (login, app start, server start, Client post, etc). For security purposes, different script roles support different domains of functionality; client scripts share User Interface access responsibilities with the server, while server scripts access databases, etc.
  
  Caruso scripts are developed within Caruso's own native development environment (IDE), much like traditional Windows applications. These scripts take advantage of a Caruso runtime language environment. Scripts execute within a Caruso container, such as server or Client software. They are NOT actual executable code fragments for a particular operating system, but rather are based on an optimized, runtime script environment, which is specifically extended to support multitier application hosting needs. Further, they are enabled and constrained by the container executable (client or server software) to only support certain types of functionality, in accordance with the security needs of a particular container.
  
  On the server, scripts execute in a protected context of a service thread. Prior to execution, the thread's runtime context is aligned to the appropriate client session, channel, etc. A particular thread has no mechanism for accessing a user session outside of its own context and is prohibited from doing so; thus protecting session boundaries during script executions. Each thread execution is guaranteed to reference a unique, strictly bounded, session container. These server session containers can maintain a variety of session objects, including databases interfaces, state variables and objects, user info, channel info, etc.
  
  A "Client-side element" refers to various elements that are provided to the Client software by the server in order to provide Client-side logic and objects as required by a particular application. Primarily, these are definitions for forms, including images, static textual elements, etc. However, they may also include limited functionality scripts for interfacing with the user and communicating with the server.
  
  
• Application Routers
  The application Router is a Caruso server that fulfills several duties for a particular Caruso server cluster. The following are the Router's primary duties:
  
  
  1. Track States of Caruso Servers within the Cluster
     The Router maintains information regarding all the servers in the Cluster. By definition, a Caruso Cluster is a group of Caruso servers that are all governed by a particular Router. It accomplishes this by communicating with the servers in the Cluster via back-end administrative channels. These servers may reside on the same machine, different local machines or remote machines. Since the Caruso administrative channels also implement the Caruso secure channel pattern, Servers may reside anywhere on the Internet, while still providing secure communications. The administrative channel communications are based on a very lightweight command, control and reporting protocol, by which the Router may collect information from a server or issue instructions to a server.
     
     
  2. Client Load Balancing
     The Router serves inbound Client application requests, by which it authorizes sessions with a target application server. In so doing, it communicates with the referenced application server and returns authorization data and instructions for the Client, by which it is redirected to the specified application server. During this process, the Router maintains both virtual and actual Client connections for each application server in the Cluster, as supported by communications over the administrative channels with the target server. The Router is aware of when the Client actually connects to the server, as well as if it fails to connect to the server for some reason. Until it actually connects to the server, the issue session authorization is considered a "virtual session". Once it actually connects and promotes a secure channel, it is considered a full session.
     
     Caruso provides all of its own routing logic. As a result, a Caruso server environment does not require any Web oriented load balancing techniques, such as "DNS round robin", stateful connection proxies, etc.
     
     This routing process DOES NOT provide any actual user authentication services, but is intended to be a very lightweight coordination protocol. All user identification, authentication and authorization is accomplished by the application server.
     
     
  3. Enforce Client versioning
     The Router maintains Client versioning information. During routing, it determines if a particular Client software install requires updating and re-routes the Client to an appropriate update service for doing so. It also tracks versioning of several other less critical Client needs.
     
     
  4. Provide Cluster Administration Services
     The Router provides an administrative channel for I.T. administration of the Cluster servers. This allows I.T. and support personal to track and manage servers and user sessions. By accessing the Cluster administration services, I.T. and support staff can troubleshoot session level issues, shutdown servers, etc.
     
     
• Application Servers
  Generally, the Caruso application server accepts connections from the Client software, by which it provides application services to the Client over a Caruso secure channel. In doing so, the application server must fulfill numerous duties.
  
  The following are several primary duties:
  
  
  1. Pre-compile all server scripts during server startup or upon administrative request, as well as service requests for application script code as needed. In this state, server scripts run very quickly and efficiently.
  2. Provide a framework for user identification and authentication services.
  3. Establish secure communications with each Client instance by negotiating secure channels during session initialization, as governed by a particular application.
  4. Provide synchronization services for Client side application elements (Client scripts, User Interface definitions, profile content, cache management, etc)
  5. Provide and enforce unique session boundaries for tracking and supporting unique application sessions. Applications are not allowed to violate session boundaries or access session data that is out of a particular session's context.
  6. Provide execution context for application scripts, where application business logic is executed.
  Similar to some 4GL environments, all of the elements of a Caruso application are stored in a database. Currently, that database is a MySQL database.
  
  
• Customer Database Information
  Naturally, a primary functional duty of a Caruso application, like Collaborator, is to store and retrieve user data. With Collaborator, user data is maintained in a MySQL database on a TRA server. This database contains all of the users project and account related data, such as project info, users, tasks, discussions, etc. It does NOT contain actual file data for uploaded files. While the MySQL database does reference user files, the actual file data is stored in encrypted files on a TRA server.
  
  
• File Servers and File Transfers
  The Caruso architecture implements its own native file servers. Caruso DOES NOT use FTP or similar protocols to transfer files.
  
  While FTP predates the existence of the web, it has some of the same issues as the web, in that it is an old design that was not originally architected for security. Like the Web, it also has morphed into a kludge of permutations and extensions in an attempt to make it secure. Caruso starts over with its own protocols for transferring files.
  
  The Caruso file transfer solution provides for a file transfer cluster comprised of a File Transfer Controller (load balancer) and a collection of File Servers. The file transfer cluster supports user file transfers via application server requests. Basically, this is how the process works:
  
  
  1. The user requests to upload or download one or more files via application provided logic on the Client.
  2. The Caruso application initiates a batch transfer request.
  3. The Caruso application server communicates with the file transfer cluster to authorize and service the batch transfer request.
  4. The file transfer controller determines an appropriate file server and exchanges service request authorization information with the target file server, including generating random transfer session credentials, session connect timeouts, requested file information, etc.
  5. The file transfer controller notifies the application server.
  6. The application server notifies the user's client software.
  7. The client software establishes a new outbound secure channel connection to the File Server, using the supplied random credentials.
  8. The batch files are transferred as requested.
     
     • For uploads, the files are first compressed, if they are considered ok to compress. This is according to file extension. Some files actually grow in size when compressed, such as ZIP, RAR, JPG, etc. They are then uploaded to the file server. The file server receives the file then encrypts and stores the file using randomly generated keys that are unique for each file. The keys are stored in the application database with a reference for each file uploaded.
     • For downloads, the file is retrieved from storage and decrypted using the random keys stored in the application database. Once downloaded, they are uncompressed if necessary, and then moved to the requested download folder.
  In this manner, each batch request acquires a new secure channel to a file server. All the files of the batch is transferred using that same channel. Each individual batch may or may not target the same file server. Since some providers constrain the bandwidth of individual TCP/IP connections, this allows the user to aggregate bandwidth over several concurrent batch transfers.
  
  This process enforces application defined security policies, since files are only uploaded and downloaded based on application authorized requests. This also provides the flexibility for Caruso applications to determine file transfer security requirements, as well as user relationships to file based application data.
  
  

  VII. Summary

  The Caruso architecture provides a secure, trustable and resilient environment for the hosting and servicing of the Collaborator application. The preceding document makes clear:
  
  
  • That the individual components of the Caruso architecture have been designed from the ground up to provide a secure solution for accessing remotely hosted applications, such as Collaborator.
  • To use the Collaborator service, one need only install the low impact, secure Client software.
  • The Caruso application framework is capable of providing very user friendly, responsive applications, such as Collaborator.
    
    The preceding information was a general overview of some of the key elements of the Caruso architecture, the environment in which Collaborator is designed and hosted. For more detailed technical information, please refer to http://www.thoughtrealm.com/caruso/security.

  [1] Bruce Schneier, "Applied Cryptography", Second Edition, 1996, John Wiley & Sons, Inc.