Windstone Communications Protocol
Development Whitepaper
Original: 2005-10-02
Revised: 2005-11-07
* Commands Listing *
Table of Contents
I. Introduction
A. What is Windstone?
B. Core Features
1. Authentication Without Boundaries
2. Just Like Email, With Less Calories
3. Survival of the Geekiest
C. Architecture
D. Open Source Notice
II. Basic Concepts
A. String Manipulation
B. HTTP POST Method
C. Remote Inclusion
D. Encryption
III. Getting Started
A. Development Requirements
B. Becoming the Secret Agent
C. Command Strings
IV. Example PHP Agent System
V. Contact Information
VI. Credits
[ Introduction ]
# What is Windstone? #
The purpose of Windstone is to provide a specification to allow for secure, inter-site and Internet-enabled communication. Windstone accomplishes this by providing simple methods of transmission and reception, in a standardized form, while adding encryption to secure each communication.
With this specification, websites and Internet-enabled programs (IEPs) can communicate with each other and enhance their individual capabilities via a centralized facility.
# Core Features #
* Authentication Without Boundaries *
One of the core features of Windstone includes the ability for users to register with the Windstone server and, when Windstone is implemented as part of a website or IEP, to login through Windstone in place of using a username and password specific to each website or IEP. This allows the use of only one set of authentication data on all websites and IEPs that use the protocol, by replacing a username with an email address and a user password with a user token.
While a password is still used, it is never saved at any point. Many websites and IEPs currently rely on saving a password in an encrypted form, which is still susceptible to being reversed or circumvented. By eliminating the need for a password to be saved, that password cannot be compromised, thereby removing a potential security concern, not only for users, but for website and network administrators - when it becomes common knowledge that passwords are not held on their website or network, the systems themselves will become less of a target.
When a user initially registers with the Windstone server, a fingerprint is generated. The fingerprint for an individual user is a randomly selected group of five words from a dictionary database. These words are then encrypted using the password supplied by the user. The fingerprint can thus only be decrypted via the user's password. To further strengthen the fingerprint, it is encrypted again using a system-level encryption key and is then saved in a database. A malicious user would need to be able to break the system-level encryption and know the user's password to defeat the encrypted fingerprint. However, since the raw and encrypted fingerprints are saved together, successfully decrypting the fingerprint will only reveal the original fingerprint (which is already known).
In order to authenticate a user at a later time, the system will use the original fingerprint and compare it to the processed version of the encrypted fingerprint. The comparison process is essentially the reverse of the registration process: the system will decrypt the encrypted fingerprint using the system-level key, apply the user's password to decrypt the remaining portion, and thereby reveal the original fingerprint. If the two fingerprints match, the user is authenticated. If not, the user will be denied.
* Just Like Email, With Less Calories *
One of the other core features of Windstone is the ability to get messages to and from anywhere. The basic forms are fundamentally email and private messaging, but go one step further. For example, to check email, a user needs to login to a specific website or email client. If the user is on a different website, or if the user is not on their home computer, messages can go unseen until the user can check their messages normally. Websites or mail clients that implement Windstone, however, will allow the user to check their messages anywhere, at any time.
This is because messages are transacted through the Windstone server. While a user is logged into a particular website or IEP, the service will continue to poll the Windstone server for new messages and other information to process at regular intervals. The Windstone server in turn will check the last service that the user logged into and that their login session is valid. Windstone will then direct messages to that service to be downloaded on behalf of the user. Websites and IEPs can also receive messages, just like users.
* Survival of the Geekiest *
Essential to the survival of any technology (just like animals) is the ability to adapt to changing needs over time. Windstone's core coding structure allows for rapid extension of core features with a minimal amount of effort. After implementation on any website or IEP, additional features need only to be defined and processed by themselves -- updates of the entire structure are simply not necessary.
If it is found that a group of websites wish to implement their own features or exchange customized communications amongst themselves, they can. The adaptation to any communication need is as simple as defining it.
# Architecture #
Windstone Server is the main server that is used to manage user and agent accounts and facilitate communications amongst agent systems. Agent Software is the actual programming, or compiled code, used to create functional agent systems. Agent Systems are individual instances of Agent Software that are uniquely registered and identified as single entities. Agent systems manage and facilitate user and agent communication, usually in the form of websites or instant messaging programs.
Agent systems communicate with each other and with the Windstone server via the Windstone Communications Protocol, a messaging standard that runs on top of HTTP. Messaging is done through uniquely formatted strings of characters called Command Strings that can not only identify certain actions that need to be taken, but can also convey information and data.
# Open Source Notice #
While the actual code that runs the Windstone server's processing and switching capabilities is closed source, the protocol is open and public. The information provided in this document clearly shows that the concepts and methods used to process these communications are neither secret nor complicated. Therefore, there is simply no reason to produce a published version of the code running the capabilities, as those capabilities are essentially the same for both the agent systems and the protocol itself.
The purpose of the published command strings listing (found here) is simply to provide a basis of functionality. These commands may be extended for inter-system communication by simply adding commands and their required actions and information, but the provided commands are used to standardize what will be generally and universally accepted amongst all agent systems.
As this is a protocol and not software, the idea of making it open source is simply not possible, as such. What can be (and is encouraged to be) provided as open source for public development, is the individual agent software used with the protocol. Developers of agent software are encouraged to provide their code to the public so that it may be developed more fully and so that others can contribute and share in the experience as well.
[ Basic Concepts ]
# String Manipulation #
If you are not familiar with string manipulation or, conversely, have used it extensively, you may skip to the next section. One of the primary reasons why the protocol works (and partly what it depends upon), is that it is in the correct format. The format (when correctly manipulated) can contain and convey a wide variety of information. The format of this command string is as follows:
AAAA.*BBBBBBBBBB.*CCCC::DDDDDDDDDDDDDDDDDDDD::EEEE::FFFFFFFFFF
A. This is the command. Commands tell us what kind of request or response is being made with the command string. It also lets us know how many elements of data to expect (see F).
B. This is the agent system identifier. Each website or IEP receives a unique alphanumeric ten (10) character identifier upon registration, which is used to identify this system within the network.
C. This is the protocol version number. Generally, the version number will not change much, if at all, but it must be present. The protocol version goes with all command strings to let other systems and the Windstone server know what version of the protocol you are using. If certain versions are incompatible with each other, or if there is an upgrade or change to the protocol you are using, the version number will be used to determine that.
D. This is the transaction identifier. Usually, this is not used, so the default information that should go here is six zeros ("000000"). The transaction identifier helps to link command strings into groups for processing and is most often used during the user login process.
E. This is the sequence number. The sequence number, in conjunction with the transaction identifier, is used to put grouped command strings into their logical order. The sequence numbers have no specified numbering sequence, default start value, or length limit: the only requirement is that a sequence number must be in order from lowest to highest. When not using a transaction identifier or sequence number, the default information that should go here is a simple "X" (note that when "X" is being used in a command string by itself, it should always be capitalized).
F. This is the data section. The data section is the heart of the command string. It is important to note that, at the minimum, all data sections need to be base-64 encoded prior to transmission - at no time should there be information in plain text format in the data section.
When a command string is manipulated, it is broken into smaller usable pieces. In the example of the command string format at the beginning of this section, there are special characters between each group of letters, but the special characters are not all the same. The first step in manipulating the string is to separate the string by the first delimiter, double colons ("::"). This will result in the string being separated into the following groups: ABC, D, E, and F. The string will need to be manipulated further to split the A, B and C sections apart, using the second delimiter, the period and asterisk (".*"). This should result in all sections A-F becoming separate. At this point, it would be beneficial if all six sections were placed in their own variable. Section F is the data section and will be the only section that is either base64 encoded or both encoded and encrypted. To determine if this is the case or not, see the Commands Listing for the current protocol version.
# HTTP POST Method #
Information is freely available online in any programming language imaginable for HTTP POST, so this section will be brief. The main difference is that this is not a regular POST transaction like someone would commonly use. Instead of a user filling out a form and sending the data to the server using the POST method, we will need to initiate the POST transaction ourselves. For this to work you must create a function to initiate a POST transaction with an external HTTP server. HTTP POST transactions take the following example format when a form is submitted to an HTTP server:
POST /path/script.cgi HTTP/1.0
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
All of the variables sent in the POST action should be URL-encoded for the transaction as per HTTP. The programming language you are going to use also needs to be able to create and send these transactions as per HTTP.
# Remote Inclusion #
In order for an agent system to accept instant results for things such as login, the system must be able to remotely include the results of the POST transaction. This means that the system must be able to download a copy of the resulting "webpage" from the POST transaction. This method, just like the usage of the HTTP POST, should be freely available online for most programming languages.
# Encryption #
Many of the commands used in the protocol contain encrypted data portions. The two encryption algorithms are CAST-128 and RC4, CAST-128 being the preferred one. These two algorithms are freely available online. However, the usage and technical aspects of the algorithms are beyond the scope of this whitepaper and will not be included. It is only necessary to be able to implement and use one of these algorithms.
[ Getting Started ]
# Development Requirements #
The basic requirements for development with the protocol is the capability to perform string manipulation, HTTP POST requests, save the results of those requests using remote inclusion, and encrypt or decrypt using the supported algorithms. Database support is also helpful. All agent systems also need an Internet connection of some sort in order to work correctly. Proxy servers should not be a problem when using PC-based agent systems, as all requests and responses are initiated by the agent system itself at all times over standard HTTP.
# Becoming the Secret Agent #
Setup using the protocol is automated, meaning your system should initiate its own registration and setup itself. This is started by the system sending the SETUP_INITIALIZE command with the required information. The data section of the command string should be encrypted using the encryption key for the software as registered with Windstone previously. If you are developing the system from scratch, you will need to register a user account with Windstone, and under Options, select the option to register your software. You will need the encryption key that you used when registering the software so that Windstone can register the agent system and issue its encryption key.
When the system has sent the SETUP_INITIALIZE command, it will receive either the SETUP_ERROR or SETUP_COMPLETE command. If you receive the SETUP_ERROR command, log it so that you can view it later and figure out what went wrong. If you get the SETUP_COMPLETE command, it will include a variety of setup information that your program will need to save for future use, such as the agent system ID and the shared encryption key. This information must be saved so that the program can access it later; very little of it will change in the future.
Once your agent system has received the SETUP_COMPLETE command and has saved all of the information accordingly, it is a registered agent system of Windstone and can now send and receive commands from either Windstone or any other agent system. However, there is one more step that needs to be completed, which is associating the agent system with your user account on Windstone. This is important, as it allows you to change information about your agent system that is critical to its functionality, and also provides ownership of the agent system to you so that only you can modify that information. You will be provided with an activation key in the SETUP_COMPLETE command which you need to enter under Options to associate your agent system with you when you are logged into your user account. This takes only a few seconds to complete, and makes the agent system fully functional. If the agent system is not associated with a user account, it will constantly receive an authentication error message, and will furthermore be deleted after seven (7) days if it has not been associated with a user account in that time.
# Command Strings #
Your system will use command strings for a wide variety of information exchange between Windstone and other agent systems. A current listing of commands is always available here. The listing will also tell you whether the command is issued by you or by Windstone, and whether or not the information needs to be encrypted. Please make sure that your agent system can process these commands, as they will be the standard commands for the protocol. All agent systems must have the ability to understand and reply to these commands as expected.
[ Example PHP Agent System ]
Here is a very basic example of a functional agent system in PHP to illustrate how easy it is to create a system. This example system contains only 6 script files and uses no database, and lacks the flair, interactivity, and multi-user capabilities that would be expected of systems using the protocol. (Also, please excuse the mess. This is the actual testing bed used to test all of the protocol features. It was endlessly modified and updated, so some areas lack well thought out design.)
Download the ZIP file now.
There is also a sample user account active on the Windstone server for testing purposes. Username is test@x-mirror.com and password is 0123456789. Please do not abuse this user account and ruin it for others.
[ Contact Information ]
Please address all email correspondence to the following address: windstone@nkpcorp.com.
[ Credits ]
Developer: SoundWave
Very Special Thanks to: General Halley, X/O of CyberArmy Services and Support, for his major contribution to this project by providing editorial support.
Special Thanks to: the CyberArmy Special Operations and Security members and command staff for providing the needed encouragement for this project to succeed; CyberArmy itself for allowing this project to reach fruition; CyberArmy's zZine for publishing the initial project announcement and (I'm sure at a later time than this) for publishing the announcement of the project's completion and availability to the general public; cigarette manufacturers everywhere; Folger's Coffee; Kaizer's Orchestra for their song Bak et Halleluja which took me through the entire writing of this whitepaper in conjunctions with cigarettes and coffee; MinDistortion.net for the Flash movie short "War" for introducing me to Bak et Halleluja; and of course, NKP Corporation, for providing the hosting space for the Windstone project for over a year at X-Mirror.com so that this project could be developed properly. Thanks everyone!
|
|
