SSSDR [16 Slides]

1. SSSDR[16 Slides] Alternative to Passwords and PINs Contents The Problem to be Addressed Elevator Points Proposed Solution: SSSDR SSSDR Logic & Client-Side Walk-Through Overview of Server-Side and Process Flow Business Modeling Online Demo of Prototype Information (site and login info)

2. The Problem • PINs are simplistic, and easy to steal (or Figure Out): • At ATM’s • Supermarket Checkouts • Susceptible to Hackers when used online • Don’t Really Validate Users, and can’t be used for digital signatures • Passwords are • Complicated and difficult for People to Remember • Can be viewed when typed in • Difficult to enter on virtual keyboards (e.g. smart phones) • PINs and Passwords are not Interchangeable • Logins require adherence to complexity rules—PIN’s with only 4 numbers can’t be used as passwords (nor should they be) • PINs can only use numbers, and are usually entered in plain view

3. SSSDR – Essential Points Practical Points: • Three to Eight mouse clicks or Finger Touches, in plain view • Much more difficultfor diligent observers to figure out or steal even when it’s directly observed while entered • Based on simple (small) technology: • A few thousand bytes of code • Can be embedded virtually anywhere • Can Replace Conventional : • Computer Passwords • ATM PIN’s • Credit Card Authorizations • Digital Signatures • No Hidden or Masked Input • Simple Enough for Children to Use Business Points • Can Be Licensed as IP, or Can be Hub in Identity Verification Company • Fairly Robust Market Base • Government Applications • Terminals can be easily retro-fitted • ATM’s can adopt via software updates • Can be used on any color touch screen, or on non-touch screens via keyboard input

4. The SSSDR There are 3Main components... Component 2 The 8 Jewels: Component 1 The 4 Jewel Attributes: • Position on the Ring (1-8) • Color of the Jewel • Letter (A-H) • Icon Shape Component 3 The Account ID. In most practices it is pre-populated and hidden, such as from: • Credit Card Swipe • Login Account • From a Cell Phone

5. Walk Through With Each Mouse Click, the SSSDR Assembles Each of the 8 jewels with RANDOM attributes. Each Ring, therefore, has 8 Randomly assembled jewels making each instance of the ring very unique. For this Demo, only 4 clicks are used. The SSSDR can be set to use 2 – 8 Clicks, based on the Application and Context needs. For example, to open a document not classified on a validated previous login, perhaps only 2 or 3 clicks. For a Credit Card transaction, perhaps 6 or 8 clicks. It can be set by applications at runtime. Fourth Click... Initial Load, First Click Second Click... Third Click... Where a User Fails at an attempt to validate, an extra click is added to the retry. After the second attempt at the 8-click level, the session is denied. That means that the lower the intended click-strength, the more tries a user may get (customizable); the higher the intended strength, the fewer tries.

6. Walk-Through, Part 2 As a User clicks (or touches, presses keypad numbers, or even speaks the jewel number), onlookers may see (or hear) which jewel was selected, but not know why it was selected (The number? The shape? The Letter? The Color?) Since each ring is randomly assembled at each load and click, a given “Ring Face” might not be reproduced for thousands of draws.

7. Pass Keys Users’ Passkeys are assigned (or chosen) as 8-click Sequences based on any attribute, plus a few that can change: In addition to these, there are “Wild Card” Clicks. (Optional, but only one may be used in a Pass Key) • Any Random Click • Any Odd Number • Any Even Number • Day of Week Number (Sunday = 1, Saturday = 7) Sample Pass Keys:

8. Pass Keys are NOT Sent Over the Net: • What gets sent is a digital snapshot of the Ring Sequence Used, and which Jewels the User selected. • A Digital Snapshot of the Ring Sequence Used • The Jewels the User Selected • (The Click-Length is Derived from the Ring Sequence Snapshot Sent) • The Merchant ID and Terminal ID (more about that on next slide) • This means that even if unencrypted, an interceptor or sniffer would only get the same information he would get if he simply watched the user validate. • Over time, an interceptor couldderive the Pass Key, however, the use of Wild Cards and the changing of Pass Keys would make this more difficult.

9. The Server Role • Merchants are assigned Merchant ID’s, and each individual device used by the Merchant is also assigned a Terminal ID, A Terminal Code, and a “Green Light” Code. • The Validation Server, once having validated a User’s Pass Key: • Validates the Merchant ID (internally) • Validates the Terminal ID (internally) • Validates the Terminal Code (internally) • Responds with that terminal’s unique “Green Light” code, plus a transaction number, and records the transaction • The User Can get a receipt containing the financial details, and the Merchant ID, and the Terminal ID (but not the Terminal Code) • NOTE THAT: once the “Green Light” code is received, it is up to the Merchant and his existing financial partners and systems to process and track financial transactions. • Once the Terminal receives the “Green Light” code, it authorizes the completion of the transaction, which could be: • A Financial Transaction • The Granting of Access to Information • The Authorization of Features or Functionality

10. High-Level Flow: ATM, Credit Card, Digital Signature, Web Site, Desktop Computer, Cell Phone, Tablet, etc. . Encrypted Digital Snapshot of what an onlooker would see Terminal 1 • Ring Snapshot, Jewels Clicked 2 • User Account ID Key, Merchant ID, Terminal ID SSSDR Entry Information does not leave Server Side USER Identity Validated Internally • “Green Light” Code Validated by Terminal Merchant & Terminal Validated 4 Terminal “Green Light” Code Algorithm (Specific for that terminal, at that time) determined. • “Green Light” Code 3 • Process Transaction as Currently Processed Today

11. Examples of Merchants and Terminals • A Merchant is anyone who uses the SSSDR for Validation. • Retail • Gas Station Pump, • ATM • Register • Vending Machine • Technical Devices • Cell Phone • Tablet • Desktop Computer • Physical Security Devices • Secure Entry Devices, such as door locks to computer rooms • Safe Combinations (in which case the server logic resides inside the safe?) • Software • System Login • Digital Signatures • Application Registration/Feature Unlocks • Websites • Safety “Panic Key” • For added physical safety, a “Panic Key” can also be issued which is the same as the Pass Key, except for the first click. • If, for example, a User is forced under physical duress to enter a Pass Key (e.g., at an ATM), he can enter the Panic Key instead. • If the Panic Key is validated, a “Green Light” code will be returned and no appearance is given of the Panic Code being used, but the authorities can be alerted based on the Merchant ID and Terminal Code. Terminal location information can be obtained from data records maintained internally by the server.

12. What Can Be Done With This? • Embed it on a Smart Credit Card • Makes Stolen Cards virtually unusable on the Internet, in the Mall, at the Gas Station—even if it’s never reported stolen because every time that card is used, the User will enter in his or her SSSDR Password. • Modify ATM’s to allow users to press buttons corresponding to jewels – Requires virtually no hardware modification. Can be used at Point of Sale devices (e.g., at the grocery store check-out device). • Replace the Ctrl+Alt+Del Login mechanism on Computers. • Perfect for Tablet PC’s – Use the Digital Pen to Enter it • Perfect for Crowded Public Areas – Stop hiding fingers when logging in on the airplane • Embed User Passwords into Active Directory to control logon access to the Internal Network • Use it to verify Identify for Digital Signatures • Security Badges can utilize them for better access control to facilities. They can also replace combination locks on secure doors • Add-on to any smart phoneor tablet. Particularly useful for slates, since it requires no keyboard or keypad. • Through User agreements, this can be treated as a digital signature for credit card transactions (the “Green Light” code acts as a digital signature). This would be easier to store than digital signatures from a sign pad.

13. Business Modeling - 1 1. License the Technology and allow others to brand it Companies own the license to do as they please with it, end-to-end including the back-end server process, and pay royalties for use Potential Buyers: • Google • Microsoft • Adobe • Amazon • PayPal • Government • Credit Card / Financial • Upside: • Lower Initial Investment • IP-only transaction, so no infrastructure build-out • Much Shorter Time-To-Market • Much less Risk Exposure • Could still include hardware tech for embedded chips, etc. • Downside: • Lower revenue, less profit • No real scale of penetration • Non-tangible IP-only valuations and revenue are very risky, difficult and costly to maintain

14. Business Modeling - 2 • People register with the SSSDR Firm, and all logins are sent to the firm for validation • People have a unified password; one SSSDR Password (which can be changed at any time) for their work LAN’s, Credit Cards, Digital Signatures, etc.. • To be effective (and thereby minimize risk exposure), Users would need to register in person, with proper ID (banks? Post Office? This could be a large infrastructure rollout) • 2. Become a National Identity Verification Firm • Upside: • Much larger revenue potential • Very Large Penetration potential • Not an IP-Only Valuation • Users can benefit from: • Holistic, single-source tracking of all authorizations across all vendors and merchants • Only one Pass Key to remember, and changes to Pass Keys are universal and instant • Downside: • Huge Upfront Investment (infrastructure, etc.) • Much longer Time-to-Market • Significantly higher Risk Exposure

15. Online Demo • A Basic online demo is available at: http://qazz.co/ • Some notes about the demo: • Scripts must be enabled • This just demos the basic User Experience, not the whole validation system • There is an optional textbox to hand-enter a User Account or ID (which is not used in this demo), but normally this would be populated by the terminal: • Credit Card Swipe • Derived from Computer Login ID • Cell Phone Information (if used on a cell phone) • Etc. • This demo defaults to 4-clicks, but you can set it from 2 - 8 • There is no Server Validation (it’s just a mock validation)

16. Using the Demo Prototype Change Click Strength Here. An interesting Demo is to enter the pass key while others are watching, and see how long it takes them to crack just a 2-click Pass Key. Two Clicks are not terribly difficult to crack, but compare to cracking a 2-digit PIN when entered in plain view... Click “Show Notes” to reveal the password