EYEdentityOnline.com

I jumped off a simple question from a friend about IronKey into how I accomplish securing my portable data over at my personal blog WhoIsHahleq.com:

Post tiled A friend asked me about IronKey

As Michael Arrington at Techcrunch says, it’s hard to have too much sympathy when people give up their passwords to sites holding sensitive data, but wait… people are doing this every day on Web 2.0 sites all over the web! This site pulls in That site’s content and you need to provide your password to a page, applet, plugin, etc. to accomplish this. How many places are users entering their passwords? How many of those passwords match at how many other sites? Given how much data I can get from an aggregation site, how many sites do I need to compromise to seriously damage any given user? G-Archiver had way more than e-mail access. For some accounts there would be Google Payment information, Google Apps and all related content. Yikes!

So once again we come back to the sad state of authentication in the broader internet world. Sure banks may or may not have done something meaningful when pushed, but stop and think about all the sensitive data you have scattered around on sites that daily are getting “hooked up”. So what about the rest of the sites where we increasingly investing our time, our money, our data about our time and data… you get the idea. Whether you realize it or not, your online world is increasingly a federated world. Federation is great so long as there is solid authentication underpinning the master login. If not, federation is a terribly scary, easily and devastatingly compromisable thing.

There’s lots of noise around identity, some of it even touching on authentication, but not much. Microsoft buys Credentica. Cardspace plays with OpenID. Everyone is turning their logins into OpenIDs even though they aren’t accepting OpenIDs (does that mean they really adopted it or not?). Ping acquires Sxip. 47 new OpenID IPs launched while I was writing this article (ok, that’s an exaggeration).

However, I’m still managing my online security with Roboform in an encrypted volume protected by 2-factor authentication. Last count, I’m managing nearly 300 logins through that method most of which do not have matching passwords. Am I paranoid? Yes, clearly. Am I bulletproof? Nope. Do I want something better? Yup. TriCipher recently announced myOneLogin which has as part of its mission to bring strong authentication and reduced sign-on together. You can read more straight from them via Jon Brody’s interview about myOneLogin with IT Business Edge. Jon is TriCipher’s VP Marketing.

Where does the time go? Seems that I blinked and now it’s mid-February and my last post was late October! Outrageous! My apologies for either being away so long or coming back so quickly depending on your opinion of my blogging.

Anyway, thought I’d point out a couple links on what was a raging media topic a couple weeks ago: the Silentbanker trojan. I was interviewed by several folks about this topic and if you want to read or listen to any of that you can do so: here (Wall Street & Technology article quoting me) or here (NetworkWorld Security podcast streamed through your browser [15 mins]).

One additional point I’d make is that while this was hot news, nothing about this trojan or attack should be a surprise. We’ve been chatting about man-in-the-browser attacks for the last year and know from our contacts in Europe that these types of attacks have been used in the real world there for quite some time. Why this should be such a hot news item in the U.S. tech and financial press is disconcerting. Of course as a bit of a curmudgeon about online financial institution security practices, I point to this as just how little U.S. financials are paying attention to protecting their customers. Of course, there are certainly some numbers being used by the FI’s to back their smugness about what they are doing so far. This post is a good case in point of how bankers point to how effective their weak approaches to date have been. At least George Tubin, widely quoted throughout the article admits the data is “based on anecdotal observations, he said, because many bankers are reluctant to share their fraud rates”.

Really?! Well then whose anecdotal evidence trumps who’s? or is that who’s anecdotal evidence trumps whom’s? Dang, really shoulda paid more attention in grammar. Anyway, you get the idea. I don’t know if Gartner’s updated their statistic from last year that there are 9 million internet users sitting on the e-commerce sidelines because of security fears. Why are identity theft and phishing attacks still top of mind as we are barraged with daily reports of personal and group stories of fraud? Javelin’s report from Feb 2007 showed a second straight year of falling fraud rates (good synopsis here), great news. So maybe I’m being too harsh on the FIs?

I don’t think so. First, I’m not even being offered reasonably effective protections while the banks primarily cover their own assets. Second, I expected to be able to do far, far more powerful and meaningful e-commerce transactions in 2008 than it turns out I can now that we’re here. Aside from truly strong authentication, I expected back in 1998 to shortly be able to digitally sign and encrypt documents and never have to hear the word “fax” again in my life. I expected to have maybe a handful of logins to do all I needed to do on the internet, not the 300+ I have in my Roboform database. I expected all e-mail to be able to be signable and encryptable without being a PKI wonk. I’m reminded of a favorite song from my college days back in the 80s called “It’s the Eighties So Where’s Our Rocket Packs?“. If I was musically capable, I’d write a song, “It’s 2008, why do I need to come to the bank and use a pen?”

I am amazed at the lack of innovation in this entire area and eagerly await the first players to really bring me what I think of as e-commerce 2.0, which would be truly more powerful and impactful IMO, than the whole social-networking-web-2.0 thing has been.

Thanks to Mark Diodati for carrying on this discussion as I believe it is an important one and contrary to my apparent tone in my last post, I do think Mark knows what he is talking about. My frustration continues to be with the industry thought processes at large regarding secure authentication challenges as being too little, too weak and failing the customer.

I certainly agree that PKI is not a silver bullet for the authenticaion problem and that a multi-layered approach is necessary. I’ve addressed this at length in various posts covering: Fraud detection; Transaction authentication; Malware attack.

There are indeed a variety of attack surfaces at the client to compromise not only PKI (smartcard or not), but also biometrics. Once and for all, let’s all agree that we all agree there is no single hit, silver bullet solution. There are just a group of solutions that do different things along three primary axes: ease of use, cost and security. These three axes impact two primary communities: End-users and service / application providers. My main pain point is that not enough is being done to address the end-user’s security problems because of what I believe is a complete misperception and deeply held misperception and nearly religious industry tenet: users can’t / won’t deal with anything involving additional software download or hardware. This point is probably the only thing that Mark Diodati and I really disagree about on this entire topic.

We agree that:

• * There are no silver bullet solutions.
• * That “the only way to be totally protected against man-in-the-middle attacks is to use digital certificates or public key encryption” (Mark Diodati in referenced eWeek article).
• * Multi-layered approaches are necessary.
• * Smartcard deployments in the U.S. are dead on arrival for consumer adoption.
• * Traditional PKI is hard for users, IT departments, security practitioners and on top of that, very costly.

We mostly agree that:

• * U.S. FI’s are not yet prepared to deploy client or hardware solutions. I can’t completely agree with this as several have and continue to deploy several solutions that fall into this category, including TriCipher’s, but certainly the numbers are not overwhelming.

We don’t agree that:

• * “U.S. consumers don’t want” client or hardware solutions. Consumers have no problem downloading software that provides them value and do so by the thousands every day. While many will completely dismiss Javelin’s Consumer Online Banking Study because TriCipher helped sponsor it, even I was surprised that 62% of consumers said they would be likely to download software for improved security from their bank. I was thinking it might be say, 50%, but the findings were born out given that 69% of the study participants actually did download and use the software in conjunction with the web-study. How much higher would that number have been if it was offered by through their bank site? The number 1 and 2 most popular downloaded items at c/net’s download.com site are security related: anti-virus and anti-Spyware. It cannot be argued that users are not actively looking for and open to security solutions to use on their devices.

I merely agree with Mark that PKI is a solid, strong solution for authentication and beyond (signing, encryption, etc.). Consequently, PKI-based solutions should be more closely studied as part of the overall security solution space for authentication protecting against phishing, man-in-the-middle, man-in-the-browser and a wide variety of, but not all, malware. The main problem with PKI has always been in the implementation of getting keys to the user and managing them from there. “Pitch Alert”: This is what TriCipher has solved. Anyone that understands using an ATM card and a PIN without understanding Triple-DES, can get and use PKI properly architected and deployed in a practical manner. We even make it so that what the user wishes to use as their “ATM Card” is flexible and can even be left up to them, so they don’t have to be issued any purpose built hardware. Me, I use my MP3 player of choice as my 2nd factor. What would you use?

Time to move past mere “reassure the customer”, “feel good” solutions and move to something providing actual security and protections. I hope that clears things up a bit. Mark, we should put together a panel or roundtable on the topic of what consumers will and won’t put up with to get real security in their online lives.

To follow up on my last post, here’s the link to the password hardening Q&A with Mark Diodati. Per the article: ‘password hardening is that you do something extra to make the password harder to guess or spoof without actually distributing a piece of hardware or software to the consumer. That extra thing you do is like a second factor.’

So he’s claiming that BioPassword is able to perform their function using just the native bits of Flash that reside in the default Flash installation? Does that contain keyboard monitoring and patterning capture or does some new code need to be downloaded via Flash to pull this off (rhetorical, for those of you playing at home)? What prevents another keyboard logger from capturing the password and the patterning? This same patterning going to work on my Treo vs. or all of the 3 different keyboards I use in different postures (work chair, sofa, standing desk)?

Wouldn’t it be far better to ensure that capture of the password via any means or method, with or without any cutesy patterning capture, would gain the attacker nothing of use? What about the ability to protect against any kind of internal, total password file compromise? THAT’s password hardening! BioPassword do that? No.

As to the dancing on-screen keyboard entry stuff, that has been shown again and again to be vulnerable to screen / click capture malware. Doesn’t matter if the keys are in different places at each login, this only protects from a pixel grid attack not a screen capture attack that grabs the image surrounding the mouse at time of click so the attacker can see 3,5,9,4,A,m,r, etc. By the time you make the interface confusing enough to obfuscate the clicks, ‘Joe regular user’ is confused or irritated or picking an easy to enter and therefore guess, password. If this was all that and a bag of chips, Bharosa wouldn’t have had to move into fraud detection to support their weak, ‘pseudo-multifactor’ approach.

This stuff has been around for ages along with the ‘pick the faces you remember’ thing. Do ‘the kids’ today still use the word ‘lame’? It’s 2007 and folks are still dinking around with these kiddy toy approaches. I continue to be amazed at the half-measures being considered, let alone purchased and deployed.

Note the admission in the last answer that PKI is the only real answer. Funny how it keeps coming back down to that. Now if only there was a soluton that made PKI practical and scalable’¦ hmmmm, wonder where I might find one of those [sly, cat-got-canary grin]?

In an interesting article this week by David Berlind on why the Europeans have adopted true 2nd factor authentication vs. the U.S., David Berlind references a Q&A chain with Mark Diodati of Burton Group. The first article in the chain is on What is Multifactor Authentication? and I’d like to draw your attention to the second question: Many European security experts believe that multifactor authentication is essential for securing online consumer applications, but in the United States few banks or other financial institutions use it. Why is this?. Mark Diodati’s response is actually very interesting and not something of which I was aware.

I would however, suggest an additional idea: Higher European adoption could also be influenced by the difference in privacy laws and just general sensitivity to privacy in Europe vs. the U.S. Liability is a strong motivator. I’ve long held that U.S. institutions are concerned about protecting the transactions and hence, themselves vs. worrying about actually protecting the end-user. The end-user could be compromised and have their identities stolen or fraud perpetrated on them in a variety of ways due to a breach of an online account, but so long as the bank doesn’t incur a loss by reimbursing a customer for a $500 fraudulent transaction, the bank is satisfied. They are apparently managing this fraud loss ratio satisfactorily or they would definitely be pursuing more stringent mechanisms or having it forced upon them more explicitly than the weak FFIEC Guidance from 2005. This comes down to the difference between guarding against fraudulent transactions vs. the broader protection of user’s data; transactional, identity, etc.

Certainly there also appears to be a greater resistance by Americans to anything that smacks of inconvenience. The numbers are plain and straightforward that for every change you make to an online experience, users click away, stop and pick up the phone, etc. All things to be avoided if you’re trying to build an online channel and keep support costs low. Understandable.

However, like David Berlind, I’d be very happy to use a true 2nd factor authentication mechanism. In fact, I’ll change banks to get true strong authentication and move to doing much more online business ever after at that bank. I suspect that Mr. Berlind would put an OTP (One Time Password) into that category, but if you’ve read my blog or paid much attention to the reality of the man-in-the-middle threat, you’ll hold out for a true 2nd factor and not just another single factor (what you know). Remember that two passwords don’t make an actual second factor, even if one is only useful for a short while. Yes, I know that is a contentious statement and out of step with the mainstream view of OTPs, but I believe the realities of 2007 back it up.

By failing to offer stronger authentication and other security options and merely sticking with the bare minimum, U.S. institutions fail to capitalize on the opportunities for competitive advantage and increased online usage by a key target audience: The technology savvy early adopter. I haven’t looked up any recent studies on it, but I suspect this group comprises the mythical ‘influencers’ as well and probably have above average incomes, bank balances and credit card usage rates.

I’ll cover the next Q&A article in the chain with Mark Diodati in my next post. It covers password hardening.

Our CEO, John De Santis has an article posted over at Bank Systems & Technology. You can and should read it here or the response won’t make as much sense, eh?

While there note the three initial comments posted and my response to them is below for your review until such time as it clears moderation over at BankTech.

===================================

Thought I’d chime in here on John’s behalf and as TriCipher’s “evangelist”. I’ll address the three previous posts in order.

First, Ron Behanic, of course what we recommend is that you check out TriCipher’s novel approach and patented technology providing alternatives to cookie-based, friendly picture-based options. I’ve included some informational links at the bottom of this post to help you pursue the questions raised in John’s article.

Second, AlmostSecure, you are correct that the purveyors of cookie-based secure authentication (an oxymoron if ever there was one) also include backend checks. Our main point isn’t that these checks or fraud detection measures shouldn’t be done or don’t have value, but that they don’t actually protect consumers. Should I steal a user’s credential, log into their bank account browse around download all their transaction and personal data from the web account, what kind of havoc can I then perpetrate on that user? I won’t have set off any alarms as I won’t have done anything alarm worthy. However, I will have plenty information to perpetrate identity theft on-line and off in a variety of vectors completely ruining the consumer’s day to put it mildly.

Botnets are already being used to thwart IP Geolocation schemes and a careful scammer could readily compromise enough accounts and move enough small amounts of money without setting off any alarms to make it worth their while. We are strong proponents of fraud prevention in addition to fraud detection.

I’d also like to correct AlmostSecure’s statement that Server SSL certificates can stop MITM attacks. This is demonstrably untrue or MITM attacks would already be prevented and not a threat. SSL was always intended to be a 2-way mechanism where not only would the server authenticate itself to the user, but the client would authenticate with a digital credential to the server. ONLY when both parties perform both ends of the SSL protocol is the communication non-MITM-able (yep, I think I just made that word up, you read it here first ). SSL as used today is 1-way and useful to prevent sniffing of traffic, but does nothing to prevent MITM attacks. We’ve been demonstrating this for several years and these attacks are happening “in the wild” as we speak with readily available kits for any script kiddie to launch.

Malware may be the most sloppily used word in computer security. Malware is a category of attacks utilizing code at the client. Keyboard loggers, screen click capture, e-mail remailers, etc. all the way through to full device “ownership” fall into the bucket of malware. Sure, if a device is completely “owned” then game over. It doesn’t matter if you have a retina scanner, smart card and DNA analyzer all attached, the attacker merely waits for the user to authenticate and takes over behind the scenes. However, short of that level of compromise there is a lot that we at TriCipher provide our customers to protect their users credentials from being stolen / compromised by a significant portion of attack vectors falling into the “malware” group. We do this providing flexibility to match exactly the strength and cost of the credential type to the risk profile of the user, the application or the underlying data.

Third, mike’s post mentions “…Triciphers [sic] alternative is a PKI…”. Yup, we use PKI because it is the only technology shown to provide the properties necessary for strong authentication, digital signing, encryption, etc. Of course, everyone knows that PKI is nearly a dirty word and that’s why TriCipher’s patented technology results in a “practical PKI” with all the security properties of PKI, but without all the pain and fuss for end-users, implementers, security folks, etc.
Certainly self-serving of me to suggest it, but your really do owe it to yourself to swing by our web site and check out how we do it and how it can help your organization address your strong authentication and credential needs. Also, feel free to swing by my blog where I’ve addressed some of these issues and more. Also come share your thoughts and challenges at www.EYEdentityOnline.com.

Webcast: Consumer Authentication, Evolving Threats, and Countermeasures with Mark Diodati, Analyst, Burton Group http://www.tricipher.com/registration/consumer_authentication_webinar.html

Man in the Middle Whitepaper: http://www.tricipher.com/landing_pages/spotlight_offer.html

Man in the Browser Whitepaper: http://www.tricipher.com/threats/man_in_the_browser.html

Yours truly was interviewed by Kelly Jackson Higgins, Senior Editor, Dark Reading last week about TriCipher’s latest product announcement, Armored Transactions. Go ahead and read up over there. When you come back I’ll lay out a few more details for you.

Kelly did a nice job capturing the essence of Armored Transactions, but as the tired saying goes, “pictures speak a thousand words”. Below lays out the basic armored transaction flow:

First a couple of things to note:

• As you can see, the user is already protected from a man-in-the-middle (MITM) attack where the attacker is out on the internet in some manner. While the industry is only beginning to awaken to the realities of this type of attack now that they are occurring, we’ve worked to educate and protect our customers against this kind of attack for years.
• So what are we protecting against with Armored Transactions? Essentially, what we and others are referring to as man-in-the-browser attacks. Technically, this is also a man-in-the-middle attack since the attacker is between the victim and the target, but the attacker has moved one step closer to the user. As nicely highlighted in the Dark Reading article, the technical vector used by the attacker is immaterial. The attack may be a browser helper object (BHO) of one variety or another or some other mechanic to essentially disconnect the user from what they believe they are doing in the browser and what is actually being submitted over the wire.
• How does this attack bypass the “over the wire” MITM protections shown by the green pipes in the diagram above? The attacker has gotten close enough to the user to get ahead of the SSL stack and manipulate the session contents before they are submitted to the secure tunnel.

Now let’s walk through the actual process flow. The Scenario: Attacker has gotten a foothold at some point to manipulate the browser such that what the victim is inputting is actually different from what the attacker is submitting on the victim’s behalf.

1. Victim submits $200 to Bob’s Garage and the attacker changes it to $500 to BadGuy Offshore.
2. The Bank application posts the transaction to the TriCipher ID Vault for confirmation.
3. The ID Vault has a separate secure MITM-proof connection to the ID Tool on the user’s PC. The ID Tool is running outside the browser and consequently can be securely delivered the transaction the Bank received. I choose to refer to this as a “side-band” communication instead of an “out-of-band” situation as the communication is still over the internet vs. to a phone or other non-PC device. At this point, on the same screen, the victim is given the opportunity to view both what they intended and what was received at the Bank. If there’s a problem, the lie is shown as the browser and ID Tool contents will differ. Obviously, the user will “Decline” this BadGuy Offshore example.
4. However, if the transaction matches up, the user would click “Approve” along with providing their password to approve. This is of course optional workflow as a simple click of an “Approve” button could also be used. Another option provided by the powerful nature of TriCipher credentials, is that the transaction can be digitally signed to strengthen the non-repudiation environment for the transaction.
5. The approved transaction is sent back to the application where it is cleared for processing.

Actually pretty simple and straightforward. No extra devices for the user to deal with, same GUI environment they are familiar with for authentication, one less attack vector for criminals to exploit.

In my humble, but accurate opinion, the answer to the question posed in the subject line is… Yes. Definite oxymoron and no, I’m not calling you names, gentle reader.

That nice Michael Berman fella over at Grok Security posted up my response from last week on his web site (basically the content from my last post if you want to go get caught up), but dangled a question at the end in regard to TriCipher’s ID Tool To Go: “If I insert my USB key into an 0wned system, can that system rip the token from the key and log my password?”. You gotta know I can’t leave such a tantalizing question alone. Heck, there’s a whole bunch of ideas this question kicks the door open onto. So here goes:

This question comes up in probably 90% of all discussions of strong authentication for wide consumer use. Why? First, I think that the TriCipher story is so strong, that people want to poke holes in it and this “mythical gotcha” scenario is expected to stop me in my vendor tracks and bring me to my knees begging forgiveness for my arrogance. Second and less cynically, it isn’t so mythical and I would counsel you the same as I do my friends and family… Don’t use kiosks to do anything you wouldn’t want to print out and leave lying at the workstation when you are done, including the contents of every field, screen, transaction, etc. Actually, I generally shorten this advice to: don’t use kiosks, period. Need to do some banking find an ATM “kiosk” or call your bank. Ditto for your broker, airline, etc. You walk into an internet cafe where folks have been playing World of Warcraft and drinking Bawls all day and log into your bank, you kinda nearly deserve what’s comin’.

Why do I then refer to this case as “mythical”? Because though this is a valid concern at a kiosk, in truth there is nothing that can protect someone on an “0wned” kiosk PC. For argument’s sake, let us attach a retina scanner to the kiosk for biometric authentication. Does this make the user on an “0wned” machine secure? No, the attacker merely waits for you to authenticate and then gathers all the data they need and hijacks the session for their own purposes. In another example, there are challenge response mechanisms using detached cards and card readers such as the EMV CAP systems in minimal deployment in Europe that can adequately protect a transaction, but not all of the data in the session or even every conceivable session “transaction”.

So now like a good magician having distracted you with my off-hand, I’ll answer Michael’s question . Yes, just as an owned system can thwart invasive biometrics and expensive out-of-band challenge response schemes or even smart card deployment, an owned system could rip the pertinent contents off the USB housing our ID Tool To Go and of course keylog the password. However, bear in mind that as with all TriCipher 2-factor deployments of which ID Tool To Go is only one, we offer a range of other powerful functions to protect users and their credentials. I’ll try to be brief (yet having reread this, I fail… just a heads up):

Kiosk mode: Yep, we actually take into account the kiosk situation from a couple of angles. Primarily, in many kiosk situations you can’t attach a USB or other device and can’t run applications that aren’t already installed. We permit issuers and relying parties the ability to allow users to login with only their password and either, a) limit the user’s rights so that an owned system would then not have a fully privileged credential to perform costly mischief or, b) use one of our secondary authentication mechanisms to gain a second factor.

Secondary authentication: These are useful for a wide variety of situations ranging from password resets to device registration when “roaming” to a new PC to standing in as an alternate 2nd factor in Kiosk Mode. Of course the typical Q&A scenario (KBA, knowledge based authentication) is supported as is out of band SMS, e-mail and various challenge response scripts using the user’s telephone (typically mobile phone of course).

Key “rolling”: An approach to make theft of the portable device contents as difficult as possible is to change the pertinent bits on the removable device at every login. What does this buy you? Two scenarios: 1) The attacker copies the device, but the victim logs in again before the attacker. The attacker has an out of date set of bits that are useless to him and thus, thwarted. 2) The attacker logs in before the victim next logs in. The victim is apprised that their device is out of synch and that they should take immediate action with the issuer to revoke the credential and investigate for fraud. To our knowledge, this makes this solution the only proactive notification of possible credential compromise available on the market of any kind, let alone in the digital certificate-based credential space.

Last, bear in mind that the ID Tool To Go is just one of many 2-factor mechanisms all served up from a single, centrally deployed and managed system. The end-user has a powerful, fully functional digital certificate-based credential enabling powerful, true, two-way, mutual SSL authentication in a convenient, multi-use form-factor and all for pennies on the dollar of other traditional OTP and smart-card players such as RSA, Verisign, ActivCard, Entrust, etc.

Is ID Tool To Go perfectly invulnerable? No, it is just one of many TriCipher multi-factor form-factors running within the matrix of security vs. cost vs. usability.

Thanks to Michael Berman over at Grok Computer Security for the mention Friday, following the announcement of ID Tool ToGo. Also a nice article over at Dark Reading “Authentication Goes USB Route“.

I thought I’d respond here to Michael Berman’s comments and provide a couple confirmations and clarifications:

Yes, we use two authentication “stores”. In the TriCipher solution (our name alludes to our 3-key technology) set, we use public key crypto, but instead of having a single private key and public key, each user has 2 private keys and a public key. A private key the user controls and a second private key kept on the TriCipher ID Vault appliance. Of course, then there is a 3rd key, the public key.

For our “USB key” feature, the USB device serves as the 2nd “what you have” factor and of course works in conjunction with the user’s password. These two components are used to recreate what is best to think of as the “user’s key”. Note that loss or theft of the USB key provides an attacker no attack vector to guess or work backward to the password. Same with theft of the password. Whether phished, pharmed, keylogged or social engineered in any way, possession of the password alone is useless without the USB key.

The “user’s key” is used in conjunction with the other private key for that user kept on the ID Vault (ID Vault key). To properly authenticate both the user’s key and the ID Vault key are used to co-sign, if you will, and consequently create a standard, x.509 certificate based, verifiable signature for any client-SSL enabled relying party site. A decent analogy is going into a bank to open a safety deposit box where the bank manager has a key and you have a key. The safety deposit box can only be opened when both parties are present and perform their function.

Couple important points:

• Relying party needs no TriCipher code to accomplish this standards-based function.
• The two private keys for each user are never recombined anywhere to be compromisable in a single location.
• The user’s private key is never stored anywhere, ever.

While an understandably confusing point, no, we do not get in the middle between authenticating sites and users. We utilize the true two-way, mutual authentication SSL mechanism built into both the server and client ends. All our “magic sauce” briefly described above is done between the client and the TriCipher ID Vault directly. It is pretty accurate to think of the connection between the client and the ID Vault as forming a secure, virtual smart card. Certainly as far as all the client code is concerned, the signature is performed by a local, smart card as we again use the existing standards for signing procedures, CAPI and PKCS11.

Of course, there is a lot more to tout about the benefits of our solution, but I’ll restrain myself to hopefully clarifying a couple points this particular product function raised.