INTERNET-DRAFT S. Caldwell draft-caldwell-tbsa-00.txt Firelytics.com Category: Informational 10 August 2010 Expires: February 10, 2010 Trusted Browser Security Architecture (TBSA) Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 3, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This document proposes a trusted browser security model intended to secure the mutual automated consent between the end-user and the content provider before allowing a web browser to engage the services of an arbitrary third-party add-on, extension or service. Properly implemented, this proposed security model would create a standardized API across all browsers to further the security of e-commerce and other on-line transactions. 1. Introduction As the world moves away from the traditional desktop computer and becomes more dependent upon web applications, it is critical that the web browser through which these applications may be accessed provide robust security mechanisms which will protect sensitive data and systems from malicious parties [See Wadlow and Gorelik]. Currently there exists a considerable body of work (such as the standards describing SSL/TLS) for client and server authentication as well as the encryption of traffic between client and server. However, there exists no similar standards for securing information prior to its encryption by the SSL/TLS mechanisms. The following pages demonstrate the problems and proposed solution, which if standardized will allow end users and network administrators to establish browser security levels, and further will allow web application administrators and developers to implement server-side security levels. Accordingly, during web application operations, under this proposed model, the browser and web server would be forced to first agree that the two agree on a mutually acceptable security level before the web application is allowed to function. This framework is called "Trusted Browser Security Architecture" (TBSA). 2. The Problem, Defined ------------------------------------------------------------------- AUTHOR'S NOTE: ------------------------------------------------------------------- The problem described in the following section is a well-known attack and vulnerability that has existed for many years. The public discussion of this issue is therefore considered to be of very little value to the computer criminal community. It is the opinion of the author that the following public discussion of the issue is the best and only recourse to ensure the problem is resolved once and for all, as years of silence has not been a source of solutions. ------------------------------------------------------------------- For purposes of illustration, the author will describe a scenario using the Google Chrome web browser (5.0.375.99 beta). However the problem described can be reproduced on all major web browsers, including Internet Explorer, Mozilla Firefox, and Apple Safari. Additionally the problem is demonstrated through a simple manual operation. For ethical and legal reasons, the code for a full exploit is not made public in this document, as the author does not wish to assist malicious parties by providing a "how-to" guide for criminal conduct. 2.a. Browser Keylogging Demonstration Assume there exists a web application whose login screen is rendered as depicted below in HTML: Target Site
Username:
Password:
The site administrator considers the site to be sensitive and desires the strongest possible security. The web browser requires TLS with client authentication, and a client-side certificate has been installed on the end-user's computer. This ensures that only the end-user's computer can connect to the web server for the web application and that all communications between client and server are encrypted. The end user installs a browser extension for use with another site's content, and as required by that site, the end-user enables JavaScript. The extension, however, has been compromised and unknown to the end-user begins logging the end-user's browser key strokes. The next time the end-user accesses the secured 'target' site, the extension covertly obtains the user's credentials. While TLS would prevent the attacker from accessing the secured site from a remote system, the attacker is able to obtain credentials which can then be used to access the secured target site through the end-user's system via some arbitrary code injected through the trojan browser extension. Process 1. Open the Google Chrome web browser. 2. Navigate to some web page (see example HTML page provided above). 3. When page loads, right click page and select "Inspect Element" 4. Click "console" in the toolbar. 5. Within the console window, paste the following code: var o=document.getElementById('password'); o.onkeypress=function(e){console.log(e);} 6. Press . 7. Return to the form on the target page and select the password field. 8. Begin typing while observing the console window. All keystrokes should appear as captured ASCII codes in the console. The above scenario demonstrates a simple key logger possible through most browsers. This exploit can be enhanced to use AJAX where the attacker will submit the keystrokes captured during operation to a remote web server. While manual operation requires physical or remote access to the system to inject the code in an open browser prior to the user's interaction with a pre-loaded web-page, this exploit can be extended through the use of add-on or extension software used with many web browsers. 2.b. Discussion Given the absence of a security mechanism preventing malicious activity by browser add-ons or extensions, and given the lack of code signing or other strategies to ensure that any previously trusted browser add-on or extension software has not been tainted by malicious code, it is possible for an attacker to first introduce malicious code into an existing browser add-on or extension or to introduce a Trojan add-on/ extension from which the attack can occur. Under the Trojan add-on/extension theory, the author constructed a simple browser extension for Mozilla Firefox. This extension was intended to synchronize passwords between a user's many distributed computers, providing a centralized mechanism for password storage (i.e. the author's own web server). This test-scenario resulted in an extension crafted to secure the end-user's consent to capture and store user names and passwords, possibly blurring the lines of legality if put into actual practice. The author then conducted testing of this extension using his own personal accounts on many popular websites, demonstrating the ability of a browser extension to inject the above key logging code into the target pages and to capture keystrokes. While the code injected by the test extension was much more complex than the above demonstration, it painted a picture that defeats any SSL/TLS or operating system level security measures and makes the SAAS model of web applications a foolhardy effort without further mechanisms within the web browser. 3. Trusted Browser Security Architecture (TBSA) Simply blocking any and all browser add-ons and extensions is not a valid long-term solution to this problem. Extensions and add-ons include Adobe's Reader and Flash Player as well as other media players and even those open source gizmos end-users find indispensable. While blocking extensions and add-ons is feasible in the corporate environment, where IT policy can over-ride end-user demand, in the home and small business arena, this option simply does not exist. Often through a lack of technical education or complacency, systems are left vulnerable and site developers for banking and other institutions are left without a valid recourse. One strategy, proposed by Adam Barth, Adrienne Porter Felt, Prateek Saxena and Aron Boodman in "Protecting Browsers from Extension Vulnerabilities" (University of California at Berkley Technical Report No. UCB/EECS-2009-185) suggests a stronger browser security strategy that restricts the privileges of a browser extension, isolates extensions, separates privileges and otherwise increases the security of extensions in general. However, such strategies does nothing to allow the legitimate content-provider to be aware of or to consent to an otherwise user-approved extension running with his or her web application. Thus, where an end-user may for whatever reason believe his or her choice of browser extensions is 'safe,' or where the user may intentionally choose an extension in order to reverse engineer a web application, the site operator has absolutely no control to protect his or her intellectual property or the other users who rely upon this system. The above issue can be resolved by implementing an API at the browser which is accessible from client-side programming languages, such as JavaScript, vbScript, etc. This API would allow a TBSA-aware web application to identify and negotiate the security level of the client- server relationship before delivering privileged content. Part of this strategy would also involve a browser integrity check, completing the integration of the client (i.e. web browser) and the application or web server. ----------------------------------------------------------------- NOTE TBSA is implemented as an API accessible via client-side programming rather than HTTP headers sent to the server. This is consistent with the current trend in web application development, where an initial application 'seed' can be sent to the client and expand dynamically based on client-side demand. This strategy is a more scalable and robust approach which gives web developers the greatest amount of freedom with the lowest learning curve while not compromising on security. ----------------------------------------------------------------- 3.b. Browser Integrity Check (BIC) No security strategy will succeed without the verification of the platform's integrity. Loss of integrity could mean that the 'trusted platform' is lying about its current state, rendering any further work absolutely worthless. Because the web browser's integrity is in question, it cannot be self-determined. However, because the server most likely exists outside the network perimeter and may not own or have rights to access lower-level operating system functionality (which in its own right would create other security issues), the browser integrity check must consist of both a client and server component, as described below: 3.b.1 Client-side Browser-Integrity Check (BIC) The TBSA-compliant browser must provide a tbsa object whose methods are used for TBSA operations. These standardized methods ensure platform independence and a lower industry learning curve--two factors that increase the likelihood this standard will be adopted. The browser-integrity check is an example of this. A TBSA-compliant browser must expose the following method for its most basic operation: tbsa.browserIntegrityCheck( serverCallbackURL); When a web browser connects to a TBSA-aware web server, the web application calls tbsa.browserIntegrityCheck() through using some client-side programming language (e.g. JavaScript). This call must specify some server-side facility for the TBSA Browser-Integrity Check (i.e. serverCallBackURL). The browser will execute the browser-integrity check by performing an xmlHTTPrequest to the serverCallBackURL where it will submit its digital signature to the server: +-----------------------------------------------+ | Browser-Integrity Check | | HTTP/POST | +-----------------------------------------------+ |POST HTTP/1.0 | |From: | |User-Agent: | |Content-Type: application/x-www-form-urlencoded| |Content-Length: 32 | | | |browserName=& | |digitalSignature= | +-----------------------------------------------+ When tbsa.browserIntegrityCheck() submits its digital signature to the serverCallbackURL, the server-side arbitrary tbsa module will evaluate the digital signature to determine if the browser is to be trusted. The browser must at no time know the outcome of this operation. Thus, the server-side browser-integrity check routine will return some TOKEN only the server can interpret. This token is returned in response to the xmlHTTPrequest, and the browser, unable to process or interpret the token, is expected to return the same to the code which first invoked tbsa.browserIntegrityCheck(). The TOKEN received upon termination of tbsa.browserIntegrityCheck() must be cross-verified with the server. To do this, the code which first initiates the browser-integrity check must submit the TOKEN to its server-side component for cross-validation. In response, the server may reply with a simple boolean result or it may disconnect the session altogether. The entire Browser-Integrity Check process is illustrated below: +-------------------------------------------------------------+ | TBSA Browser-Integrity Check | | Client-side Example | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ ----------------------------------------------------------------- A NOTE ON BIC TOKEN CONSTRUCTION The construction of BIC TOKENS is completely arbitrary, but any strategy should ensure the TOKEN is of reasonable complexity to ensure such a token cannot be easily guessed. For this reason the BIC TOKEN must not be some value the browser might determine by analyzing the web application. It is suggested that this value should be a sha512 hash of some random string of no less than 8192 bits (possibly including a timestamp. ----------------------------------------------------------------- 3.b.2 The Server-side of Browser-Integrity Check (BIC) The bulk of TBSA must be implemented at the client side. However, to realize the benefit of TBSA, some server-side body is needed. This server-side TBSA library must be platform- independent, and it must be easily applied in any of the several common server-side programming languages (e.g. ASP.NET, PHP, Python, Perl). To implement the browser-integrity check at the server-side requires any TBSA server-side library to have two components. The first is tbsa.bicValidate() and the second is tbsa.bicXvalidate(). tbsa.bicValidate() is the module which is exposed as the serverCallBackURL used at the client side to obtain the BIC TOKEN. This method must be aware of X.509 digital certificates and capable of validating the same. This may mean that tbsa.bicValidate could use an existing project such as openSSL to validate the certificate or it could apply some proprietary strategy. The tbsa.bicValidate() method must also be capable of generating the random BIC TOKEN for return to the calling entity. This is a simple matter of generating a random string of bits then performing a SHA512 hash operation on the same. However, this TOKEN must be cross-verified through tbsa.bicXvalidate(). Thus, the TOKEN must be stored for a reasonable amount of time in some server-side repository. It must also be able to age-out old TOKENS. tbsa.bicXvalidate() is the counterpart to tbsa.bicValidate(). This method must be able to recieve a TOKEN from the client-side and compare the TOKEN to the TOKENS registered by tbsa.bicValidate(). Further, to minimize the attack surface of registered TOKENS, the tbsa.bicXvalidate() method must remove any TOKEN it cross-validates. Removing cross-validated TOKENS conserves server-side storage also resources, but the primary purpose is to avoid increasing the probability that some browser may 'guess' a valid TOKEN and spoof the TBSA framework. 3.c. Signed Third-Party Extensions and Add-on Software TBSA requires any 'trusted' browser, third-part extensions, or add- on software be digitally signed. While it should remain possible to install and execute unsigned extensions and add-on software for backward compatibility, only those software packages which are digitally signed should be considered 'trusted.' 3.d. TBSA Extension Privilege Levels (tbsa.extensionPrivileges) Browser extensions are the largest security risk in the current web application environment. This risk arises largely from the lack of any boundaries or limits on the extension-space. Web servers are unable to limit the browser add-on/extension or to verify their integrity if they are needed for the operation of the web application. The TBSA client-side API provides tbsa.extensionPrivileges() and four security levels for the control of any browser extension: +--------------------------------------+ | extensionSecurityLevel | +---+----------------------------------+ | 0 | Allow All Extensions | | 1 | Allow Signed Extensions | | 2 | Allow Specific Signed Extensions | | 3 | Disallow ALL extensions | +---+----------------------------------+ When a web browser connects to a web server, the browser extensions are assumed to operate at some privilege level set by browser design and user permissions. Where the web application is TBSA-aware and the browser is TBSA-compliant, the application may invoke the tbsa.extensionPrivileges() API call to either determine the current security level or to negotiate a higher security level. tbsa.extensionPrivileges( intLevel, arrAllowedExtensions=NULL ); ---------------------------------------------------------------- WARNING Caution must be exercised when implementing the browser TBSA API. Calls to tbsa.extensionPrivileges must NEVER be allowed to negotiate a LOWER extension privilege level than the user's minimum (default) privilege level. ---------------------------------------------------------------- Assume a web browser connects to some TBSA-aware web server and requests a web application. This web application would, presumably first perform a browser-integrity check, as described in the preceeding sections, and then, if the browser's integrity is verified, evaluate and negotiate any browser extension security level. This second security check may look something like the example below: bicValidate In the above example, the web application instructs the browser to set a minimum browser extension security level of 1 ("Allow Signed Extensions"). The browser evaluates the request against its internal preference (i.e. the internal minimum privilege level). If possible the browser will elevate its privilege level to the requested level. Regardless of the outcome of any internal operations, the browser will return its CURRENT browser extension security level. Thus, in the above example, where the browser is NOT TBSA-compliant, the call to the tbsa.extensionPrivileges() method would result in a zero or null value which would cause an alert to be raised informing the end user that the web application cannot be run on his/her platform. However, assuming a browser processing the above script is TBSA- compliant and the browser's internal default privilege level is equal to or higher than the input value (1), the above example would allow the web application to load. This presents a weakness for the above example that can be best addressed using a switch() statement and fall-through to dynamically negotiate content rendered based on TBSA compliance: In the above example, the web application could respond dynamically to the browser's TBSA compliance level. Assume, for example, that we have an travelling end-user who must remain connected to some corporate web application. The user most often uses a corporate laptop computer to engage the web application, but on one given trip the user's only access is through a public computer at, say, some coffee shop. While on a trusted TBSA-compliant computer, the user logs in using only a username and password. But when the web application detects that the browser at the coffee shop is not TBSA compliant, it executes a different user login mechanism whereby the user must provide not only username and password but a one-time passcode provided via automated telephone message or other means. Another use of the above example is to disable specific features and content (such as a banking site which may not allow wire transfers or other operations without a TBSA-compliant browser). The tbsa.extensionPrivileges() API call can request a browser to allow ANY extension to operate. It may also require that ONLY signed extensions be allowed to operate. At the opposite end of the spectrum, the web application may require that all signed or unsigned extensions be blocked from executing on the web site. This leverages existing mechanisms in most web browsers and will impose a small implementation overhead. The interesting feature of this API call is its ability to specify a set of known extensions that may run, banning all others. Thus, where the web application includes a structure such as the following, the browser may idenfify those extensions which it knows and trusts: -------------------------------------------------------------- NOTE When the web browser engages a TBSA-aware web application, it is presumed that the web developer will have designed the system to first implement all TBSA security checks before proceeding to render sensitive information to the browser. However, nothing should preclude the web application from re-engaging the browser's TBSA API to reset or re-evaluate the TBSA privilege levels or integrity checks. Thus, it is possible to elevate the required security when performing login or other sensitive operations, while relaxing these controls at other times. -------------------------------------------------------------- 3.e. Extension-Integrity Check (EIC) TBSA integrity verification starts with the browser integrity check described earlier and continues to the extensions themselves. Any browser-extension which is TBSA compliant must provide a valid digital signature. This signature may be used by browsers, the operating system and by engaged web applications to verify the integrity of the extension, using the TBSA API. 3.e.1. Client-Side Extension-Integrity Check (EIC) At extension privilege level one (1) or higher, as described in the above section, a browser extension may be considered 'trusted' and therefore must be subject to verification processes. Unsigned extensions are not subject to verification as they are ineligible for 'trusted' status. The integrity of a 'trusted' extension may be verified by a web application using the tbsa.validateExtension() API call: tbsa.validateExtension( strExtensionName, strServerCallbackURL ); As with tbsa.browserIntegrityCheck(), the browser cannot be trusted to perform any client-side security operation under TBSA. Otherwise it would be feasible for a malicious party to construct a client- side exploit of the TBSA model. Good security principles dictates that the perimeter must be well established between client and server and all sensitive operations must be performed at the server until the integrity of the COMPLETE platform (including extensions) is verified. For this reason, a call to tbsa.validateExtension() must specify a server callback URL with which the browser will call the server to submit the digital certificate of a named extension. The name of any extension passed to tbsa.validateExtension() must match the name of the extension identified in the certificate, and the server must be able to validate the certificate chain for the certificate. Once the server-side module (identified by the call- back URL) has verified the extension, the server will generate an integrity-check verification TOKEN and return the same to the browser. The browser will then return the TOKEN to the calling structure, which must cross-verify the extension's integrity by submitting the TOKEN to the server's TBSA cross-validation API. At this point, the server may either respond with a boolean 'true' value indicating "extension valid," or the server may respond with a boolean 'false' indicating the extension's integrity check failed. A web application's server-side could also discretely flag the session for termination and block any further communication with the client browser, at the discretion of the web application's developers. 3.e.2. Server-Side Extension Integrity Check (EIC) The server side of an extension integrity check is facilitated by two methods (tbsa.eicValidate() and tbsa.eicXvalidate()). The first method is exposed indirectly via the server call back URL to validate the digital signature and generate the validation TOKEN the server will later cross-validate. When the TOKEN is returned to the browser and the browser returns the TOKEN to its arbitrary calling structure, the calling structure must make the server-side tbsa.eicXvalidate() API call in order to complete the validation process. At the server-side, when tbsa.eicValidate() is invoked, a TOKEN must be generated regardless of the validation outcome. The browser must not be able to discern from the TOKEN whether or not the integrity check has passed or failed. This protects the validation process from tipping its hand to the browser which (being suspect) could craft a passing validation token for cross validation or otherwise spoof a lesser strategy. When tbsa.eicValidate() generates the validation TOKEN, the token must be returned to the browser as well as stored server-side for validation. In order to reduce attack surface on the TOKEN space, the eicValidate() method should also be expected to age-off any old TOKENS in its store. No TOKEN, therefore, should be allowed to remain in a token store for more than a few seconds, as cross- validation should be a relatively immediate process. At the other side of the server-side validation process, the tbsa.eicXvalidate() method must be able to look up and compare the TOKEN received from the web application's client-side code to any TOKENs located in the token store and to return a boolean 'true' if the TOKEN exists or otherwise respond as appropriate to the web application's design if no match is found. Further, the cross- validation method must remove any TOKENS it has found matching a given value. This too reduces the attack surface and prevents a replay attack against the system. 3.f. Ajax Privileges Ajax is a powerful tool which is essential in web application development. However, this also allows for many vulnerabilities the web application developer cannot control. Thus, though there may be some extension which meets the standard for 'trusted' status, once this extension has access to the DOM, it is possible for the extension to share information in an unexpected and unauthorized manner with some third party. To avoid the abuse of Ajax by extensions or other code-injection strategy, TBSA implements Ajax privileges: tbsa.ajaxPrivileges( intLevel, arrUrlList=NULL ); +-------------------------------+ | ajaxPrivilegeLevels | +-------------------------------+ | 0 | Allow All | | 1 | Allow Specific HTTP URLs | | 2 | Allow Specific HTTPS URLs | | 3 | Block All URLs | +-------------------------------+ The default ajax privilege level must be assigned by the end-user or browser design. No web application should be allowed to reduce this default privilege level. Web applications may only increase or identify the current privilege level. When a TBSA-compliant browser engages a web application, the application may query the browser for or request a specific Ajax privilege level in the same way the application may do so for the extension privilege level. For example, a web application may include a block of code similar to the following: In the above example, we use a switch() ladder at the client side to process the TBSA Ajax negotiation. Assuming we wish to lock down all thrid-party Ajax transactions, and the browser responds with any value less than our requested level 3 lock-down on Ajax, our web application should respond by refusing to proceed. Alternatively, if the web application is accessed by a browser but refuses to lock-down the ajax privileges as we have requested, the application could show an error message or warning that notifies the end user of the problem and asks that they agree to proceed (thereby making an informed decision). Content could be restricted based on the above script given a browser's response in order to minimize the risk to security while not completely disabling a customer/user base. When restricting Ajax privileges to specific URLs, a call to tbsa.ajaxPrivileges() must be given a one-dimensional array of strings that describes URL of every allowed site. TBSA must also allow the dynamic reconfiguration of the Ajax privileges. Thus, a web application could begin with a complete ajax lock-down and then slowly introduce allowed URLs as the site requires, minimizing the attack surface at any given time. 3.g. Password Encryption The example in the earlier problem statement involved stealing a value from some password field on a web page using JavaScript code injection. While the other measures specified in this document could prevent many attacks of this nature, password information is nonetheless stored in cleartext. A TBSA-compliant browser should encrypt this information as it is input by the end-user. To facilitate inline password encryption, TBSA-compliant browsers must provide the following API calls: tbsa.passwordEncryption( publicKey); The server can, therefore, configure the means by which the browser will protect password fields. The server may set an arbitrary public key for use with the AES encryption algorithm using the above method. When a field is specified in some website using the HTML tag with a field type of "password," a TBSA-compliant browser should ensure the field value is encrypted as key strokes are encountered. Because the server is specifying the public key of an encryption scheme the browser may only encrypt the password information without any risk of the cryptographic system being compromised by some third party. Also because the server is establishing the public key cryptography parameters, the browser must only perform the encrypt operation then submit the information to the server, where it can be decrypted. 4. Security Considerations There do not appear to be any security considerations associated with the Trusted Browser Security Architecture at this time, other than those expressed elsewhere in this document. The TBSA is intended as a loosely defined framework of client-server interactions, which when implemented by specific web browser developers/vendors may reveal implementation-specific vulnerabilities or security concerns that are best addressed on a case-by- case basis. 5. IANA Considerations There are no anticipated IANA Considerations. The subject discussed in this document do not alter the specifications for any internet identifiers. The proposed TBSA is intended to operate at the application layer of the OSI reference model, and has no impact on the other layers of said model. 6. Conclusion The solution proposed herein is intended to be backward compatible and to impose the minimal administrative overhead and industry investment to address the described problem. For this reason, no new protocols are needed. Nor are any server-side changes required, other than the implementation of TBSA-aware code within the web applications. The key to addressing the described vulnerability is to implement TBSA within all browsers and to enforce the TBSA at the server-side through the use of TBSA-aware code within those applications which require the additional security. 7. Contributors 8. Acknowledgements The following persons are acknowledged for their feedback and peer-review of this document prior to submission: Tristan Slominski Daniel Molina Wegener(dmw@coder.cl) Phil Salemi (phil@firelytics.com) Keith Chadwick (keith.chadwick@magma.ca) 9. Appendicies There are no appendicies at this time. 10. References Wadlow, T., Gorelik, Vlad. "Security in the Browser." Communications of the ACM. Vol. 52, No. 5. May 2009. See also Barth, A., et al. "Protecting Browsers from Extension Vulnerabilities." University of California at Berkley. Technical Report No. UCB/EECS-2009-185 http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS- 2009-185.pdf. December 18, 2009 11. Author's Address Sam Caldwell POBox 2401 Round Rock, Texas 78680 512.963.7805 mail@samcaldwell.net http://samcaldwell.net skype: x684867 12. IPR Boilerplate