ZSentry Identity VerificationZSentry provides high-value identity and address verification, with a multilevel, multi-channel, varied, adaptive, and ongoing (also after registration) evaluation.
With ZSentry you establish your identity using your own email address as the starting point. You can use your identity anywhere, including third-party websites, with privacy that you control.
User authentication by ZSentry uses a two-factor strong authentication process with a Usercode / Password digital certificate. This process is a direct replacement for, and resembles, the familiar but deeply flawed username / password user authentication, which largely avoids user education and directly supports usability. ZSentry login is designed to prevent phishing, dictionary attacks (even if a user chooses a weak password), and other vulnerabilities, with no password or username lists stored anywhere, not even encrypted.
ZSentry Identity Verification is provided by the ZSentry registration service (ZS Registration), which tells the ZSentry Issuer (ZS Issuer) to issue ZSentry Credentials, as follows:
If registration is granted, ZS Issuer sends a confirmation message to you with your ZSentry Usercode and use instructions. The confirmation message verifies that we are able to get mail through to you, and protects you in case someone forges a signup request in your name. The confirmation message is also part of the challenge-response authentication loop, where ZS Registration authenticates you and your email address by a challenge-response test during your registration procedure. The test is satisfied when ZS Registration verifies positively whether an unpredictable code (your Usercode) sent in the confirmation message to your email address is timely read and used by you for login. This test confirms your registration request and verifies that you control both the password to that mailbox and the password to your ZSentry account.
A preliminary test may also be applied by ZS Registration, in some cases, when you are asked to first reply to a confirmation email sent to you; this email contains an unpredictable code (your Return Code) that you must send back to ZS Registration before you receive your Usercode.
ZSentry identity validation uses trust narrowly, as "reliance on qualified information". Trust is quantified in terms of extent of reliance (larger extent, more trust). A decision to trust someone, the source of a communication, the name on a certificate, or a record must be based on factors outside the assertion of trustworthiness that the entity makes for itself. More factors, and more variety of factors, may lead to a higher trust value. They may also lead to a lower value, by uncovering elements of distrust. The final trust value can be positive, zero, or negative (distrust).
ZS Registration, thus, does not trust the initial registration contact by itself, and takes advantage of the fact that it does not happen in vacuum. The user must have a previous and ongoing contact with the service providing the email address that is being registered (e.g., a Gmail account). That email service may or may not have the full extent of trust needed to be a trusted introducer for the needs of ZS Registration, but it is a point of trust that can be evaluated and used to contribute to a final measure of trust. The same mechanism can be used for recipients, where ZSentry can evaluate (under a recipient's request) whether a sender meets the trust criteria for even sending a Zmail to that recipient, and/or qualifying that trust to the recipient before (or after) the Zmail is read.
Trust is a "slow" process, in that "trust must be earned". We see a counter-example in high-pressure sales tactics, that may even rise to the level of fraud, where an element of urgency is added to win over the expected time factor that the victim may intuitively require.
ZSentry uses this property of trust by evaluating whether the user is successfully communicating over time with some number of people, where the variety of this set of people is also relevant. Warning and non-conformance requirements are derived from these measurements at various levels, for example if it all happens too quickly, for many recipients, with very high variety.
Another aspect of trust as a "slow" process is used beneficially by ZSentry during registration and (optionally, as requested by a recipient) for verified identity services in qualifying the extent of trust that verifiers (recipients) may have on a user (sender). Based on social or professional networking, ZSentry is able to effectively refer to a user's relationships or just even prior communication established online with other entities, and statistics of use, in defining an assertion of identity for that user (identity assertions are refreshed after registration).
As used by ZSentry, identity does not only refer to an attribute (name) or some aggregation of attributes (name, address, credit card) but, even more strongly and effectively refer to relationships ("Is there an identity relationship between the true owner of this Mastercard and the person presenting it to me?"), connections ("Is this the authorized email server for that email address?"), absence of connections ("Is this email address not covered by the ZSentry Name Protection Policy?"), and other connection qualities. It's not about one authoritative channel either, to vouch for the identity, but using multiple and varied factors to prevent a single point of failure.
Furthermore, the trusted introducer function provided by ZSentry does not need to be carried over forever. You are not limited to ZSentry as the single provider, this is not a lock-in. Much like a booster rocket, once the transaction starts, other sources of trust are introduced (e.g., who do you know that I trust and can verify you by? What is your signed library key?) to the point that the ZSentry introducer function can be jettisoned without prejudice. There is no "trusted ID" that will suddenly lose all its evidence value if not renewed.
ZSentry "Sans Target" Protection
Your identity is uniquely protected online by ZSentry. Your login credentials and your keys are not stored anywhere, so that there is no password or user key list that could be attacked online ("Sans Target"). Read more
Without a key anywhere to be found, your name, email address, and all your files, which are encrypted, are de-identified and have just gibberish content if captured by an attacker. ZSentry further protects your identity, with name and email address authentication provided by cryptographic challenge-response with two-factor authentication and anti-spoofing.
ZSentry Sans Target technology also helps allay data storage security concerns, both locally and in the infrastructure. This is even more important in the context of "cloud computing" and SaaS, when user data may be stored in the "cloud".
SAML Identity Provider (IdP)
Once you have your identity verified through ZS Registration, you can use it at another place through the ZSentry SAML interface and you do not have to worry about your identity being stolen online. ZSentry uses its "Sans Target" technology (explained above) to protect your login credentials and keys, whereas the SAML identity authorization does not carry them either.
Thus, the ZSentry Identity Verification technology can be used by third-party solutions without ever exposing the users' private data, passwords, keys, or data. Read more at SAML & SSO
Trust is Good, Control is Better
Trust can also be viewed as that which can break a security design. In other words, when we trust A on matters of X, if that trust fails then we have to assume that "matters of X" can take on any possible value — for example, a value that we may not expect or want. ZSentry uses the principle that, for higher assurance, it is better to control than to trust. However, in verifying identity, one is often limited in what can be directly controlled and verified. That is when trust may be used, but it must be used well.
ZSentry identity validation uses trust as a form of open-loop control, following the extensive work on identification and trust in Information Theory terms by E. Gerck (1997), which can be applied to machine (IT processes) and human interactions.
Unforgeable Authentication, PKI, PGP, Adaptive Security
ZS Registration (summarized above) supports multiple-authority models, including federated authority, with centralized user administration and control delegation, and common authentication architectures, such as RADIUS (Remote Authentication Dial In User Service), LDAP (Lightweight Directory Access Protocol) and Active Directory, as well as X.509/PKI (Public Key Infrastructure) and PGP (Pretty Good Privacy).
ZS Issuer authentication is equivalent to PKI unforgeable authentication, but without purchasing a CA certificate and having to safe-keep the private-key. ZSentry also takes the good points of the WoT (Web-of-Trust) approach in PGP, but solves PGP's certificate revocation problems and the WoT's asynchronous maintenance difficulties, which prevent PGP users to know whether everyone in their authentication rings has a valid entry.
ZSentry identity verification supports the native ZS Registration, as well as PKI and PGP. ZSentry extends PKI and PGP standards in significant ways. The unforgeable identity authentication of both name and email address by ZS Registration solves some critical usability and security problems relating to key-signing and certificate distribution in PKI and PGP. Another important issue solved, of course, is the problem of initial contact. ZSentry allows user identification for secure first-contact and first-reply without previous interaction (e.g., exchanging passwords, requiring registration) or work (e.g., searching a directory, solving puzzles), and provides a number of life-cycle control functions, including release, self-destruct (expiration), and delivery verification, allowing finer control of the user's identity.
ZSentry uses Adaptive Security to protect user identity and its use, with state-based access control that computes response based on policy as well as previous, current and expected user actions. This allows ZSentry to react more tightly to individual acts, rather than using a canned response. This includes evaluating threats in real-time and quickly isolating potential attacks, while rating and reporting them for centralized administration measures. As the system learns new threats, any step of the identity verification process may be updated as needed, for example the ZSentry Name Protection Policy.
Preventing false login (e.g., by stealing a user's credentials with a key-logger) and duplicate use of the same account, may be a threat in some cases, especially with SSO. In addition to ZSentry Adaptive Security, which helps allay such concerns, organizations may require PoP (Proof-of-Possession) of a physical token or mobile device for access, including a fresh second-channel challenge that changes for every authentication, for example as offered by ZSentryID [PDF] >>
Organizations may require additional ZSentry modules, such as identity verification by a notary, Dun & Bradstreet D-U-N-S Number verification, Credit Card and address validation, or as mutually defined. These options can be complemented with the use of ZSentry Director, where the customer physically controls the first encryption layer, so that online servers do not know the message.
ReferencesMailbox Authentication, Challenge-Response Code: Basically, ZSentry embeds the user's sent message with a digitally-signed, timestamped, unpredictable, unique, and long enough challenge-response code (CRC) that is not visible to users. When the recipient clicks on the message received, and before the message is decrypted, ZSentry receives back the CRC and verifies whether it is valid and has not expired.
Pseudonym usage and other topics on identity verification: ZSentry Registration FAQ
Questions? Request a Support Ticket if you need more information.
|Main Technical Notes|