Banker’s Trust: An Interview with Guy Tallent

by rthieme on April 1, 2000


Identrus’s CEO has a talent for running the financial  industry’s electronic trust infrastructure.


Q: What does Identrus provide that is truly unique?

A: Through its banking partners, Identrus provides universal signing and legal enforcement capabilities to corporations engaging in business-to-business e-commerce. For those companies, the ability to sign and bind trade partners into business arrangements is essential. This can be solved in a number of traditional ways through hand-written messages, hand signatures, faxes and couriers. E-commerce, however, is about converting that solution to the electronic network, where one needs to prove that the person who signed is able to sign and is in fact the person who did sign.

Identrus’s unique selling proposition is that I can use the same utility I sign a contract with to sign messages or contracts with all of my trading partners. I don’t need a dozen different user IDs and passwords. I can have a single solution for all contractual, messaging and signing needs.

What problems have you solved with the Identrus solution?

For companies with bilateral contracts or arrangements, every bilateral electronic   arrangement must have a governing contract and set of rules that define risks and         liabilities. If I do business with only one party, it’s easy to put this into place. But if I have 100 different relationships, I’ll need to administer 100 different legal regimes—some at my control, some not—as I migrate my business online.

Identrus creates a single e-signature rulebook so that a company knows what enforceability means, what a dispute process looks like and where liability sits. hat’s at the company level from a risk management point of view.

From the end-user perspective, there are similar efficiencies. Online users in the business community typically have five to seven user IDs and passwords, excluding internal passwords. And e-commerce is just beginning. It will grow from $15 billion in current revenues to $3 trillion over the next four years. If I use the same password for multiple IDs and write them down or use a cheat sheet taped to my PC, then risk controls for good user-ID management fall by the wayside. Through Identrus, the end-user only has one data token or one ID, a physical ID that is warehoused in a smart card and is something to hold or control and activate by a passphrase. It’s similar to an ATM card. A smart card-based token is a single-purpose activity, so it’s easily managed from an end-user perspective.

Because I’m asked to engage my certificate to apply a digital signature, there’s a process administered through the application software itself that says, ‘This is important, I am now engaging my customer in a transaction and applying my signature.’ From a legal perspective, that’s a very powerful statement in terms of intent.

If a business does what you say, will you indemnify it? Am I safeguarded by participating in your network?

Absolutely. We’ve invested a lot of time and effort in working with financial institutions and legal environments to put in place a robust set of operational procedures and rules that define how a bank identifies its customer, and then how that customer administers distribution of its certificates to employees.

We allocate risk and liability to areas where it’s best controlled. A company authorizing employees to use certificates also has a responsibility. Their employees are charged with engaging in commerce, and they’ll be using certificates to sign and bind the company. So the first line of defense is within the company itself. If there is a problem in the transaction and the cause flows back to the company, there’s an arrangement with their financial institution already in place saying, ‘If you created the problem, you bear the responsibility.’ If the bank or Identrus created the problem, then they bear responsibility.

Many security professionals are concerned that ‘absolute security’ cannot be guaranteed. You’re saying that you guarantee not absolute security, but acceptable risk?

Exactly. Trust is binary. There aren’t multiple levels of trust; you either trust the signature or you don’t. To allow different levels of service, we allow the receiver of those certificates to activate various levels of risk management on their own behalf. If they choose to accept an ‘I-issue’ or ‘I-compliant’ certificate, they can simply accept it and bear 100 percent of the risk. That’s the ‘known-trading-partner-to-known-trading-partner’ model. It’s low cost with a high degree of flexibility.

With a trading partner I see infrequently, I can check randomly to be sure the certificate that was good the last time I used it is still good today, that nothing has changed. There are options in that situation that the application can apply through business logic. It can perform a validation check and gain a base level of assurance that it was issued by the institution, and is still good today. If explicit assurance is required—a specific guarantee of the certificate as it’s tied to a transaction—I can request and receive at the time of the transaction a warrantee from the issuing financial institution that, in fact, the process is sound. If it’s not sound and the warranty was obtained, the bank is the first line of defense for resolving the dispute. The bank works with the customer to determine whose problem it was and allocates risk accordingly.

Identrus includes ‘solution partners’ and member banks, all of which bring their current applications to the table. This expands the complexity of the model exponentially. By creating a single token, you simplify problems, but you also simplify theft of the token. Also, smart cards can be cracked in a number of ways. Does having one token make you more vulnerable than having 20? There is no technology out there that is not crackable. Control and response are the keys to controlling risk in any environment. That is our expertise. As we balance commercialization of a technology with real-world practicalities—what can be cracked and what can’t—we are constantly balancing one against the other. Twenty user IDs and passwords are complex for criminals, yes, but also for users, and therefore commercial use suffers. The complexity of administration suffers. If I suspect one ID or password has been compromised, should I revoke and reissue all of them?

By focusing on just one, you simplify user experience and give the user a broader ability to control that token. If there is a problem, you have a clean line of command to administer a solution and manage risk. There’s a number to call to report a problem. Revocation can be immediate. Quicker risk management must be adopted as any form of electronic security is commercialized.

From another point of view, how does one detect whether or not there’s a problem? This is where the validation activities we’ve set up with our banks are important. The issuing institutions are points of validation as well. They know their customers and can adapt usage patterns and anomaly detection technologies, just as they have in the credit card world. So procedures will be in place to identify patterns that diverge. A bank can do an assessment before a company even knows there’s a problem. The bank is the first line of defense, so they’ll have every economic incentive in the world to monitor and manage it.

Is public-key infrastructure (PKI) adequately secure for this task?

PKI is our ‘go-to-market’ technology. The rulebooks we’re writing address what it means to identify a customer and apply a credential that says, ‘I accept,’ to a message. It is an electronic attestation, and that’s what trust is about. The delivery mechanism, the state-of-the-art technology, is currently PKI. Others will evolve, but so far, where scalability, robustness of implementation and security are concerned, PKI is the clear winner.

PKI has been around for almost 25 years. It’s had such a long life cycle because it hasn’t been commercialized. By commercializing PKI solutions, we’re shortening that life cycle. It’s in our interest to evolve quickly.

Didn’t we have similar problems in the past concerning issues of identity and credibility? Every time technology gave birth to new forms of communication—letters of credit, written documents—we had to learn how to verify signatures.

You’ve hit it right on the head. If you think practically about the killer app for e-commerce, it isn’t an app at all—it’s a simple signature. That signature cuts across everything we do. Signatures drive commerce. Identrus is focused on providing consistent, digitally enforceable signatures and identity, and the identities that back those signatures. We’re not in the application space. There are others in that space building value-added solutions, but every one requires some form of a signature that says, ‘Yes, I will buy; yes, I will deliver.’ The signature ensures trust.

So you’re building the infrastructure or the context and leaving the content to others?

Right. What we’re doing is not that different from what has been done in the past. But a new media allows new things to be done. When fax machines came out, there were huge issues as to whether fax signatures would be legally enforceable.That was a quasi-bridge between the world of couriers and handwritten work and where we are today. You could still physically compare signatures in real-time in a court of law. In the e-world, you cannot rely on that. That’s where PKI and the ability to attach a private key to a person can enable you to do something very close to getting to that handwritten signature.

Will your standards be open and public?

Absolutely. We asked our banks what open protocols we could use off-the-shelf. We’re 100 percent compliant with all the PKI trappings. The key question is, how do these various public standards fit together in a controlled and commercial business sense? In order to be commercialized, PKI has to be embedded in the applications themselves and enable those applications to support certificate usage. In order to do that, we have developed basic PKI toolkits, which are currently in trial. We have to be certain it works. We have also contracted with a number of our technology vendors to begin their own commercial implementations.

Ultimately, our specifications will be distributed for anyone to use in any context.To get the protections of Identrus, you have to be plugged in through one of our financial institutions, but the specifications will be open.

In the domain of computer security, don’t you think people often operate according to an obsolete model of trust?

I look at that practical concern this way: End-users have to be accountable for their actions. Relationships with financial institutions have several components.There are certain obligations that I agree to as a company. I will protect whatever structures and facilities I have inside my company to prevent compromise. If I do not comply, the financial responsibility flows straight back to the company that caused the breach.

If someone is there to protect that company and absolve them from risk, I would expect a loosely controlled risk environment. That’s not the case in traditional banking relationships—for example, funds transfers and cash-management treasury workstation environments. The model we use already exists in those relationships today. Every partner bank has a software solution on the desktop of their major corporate clients, enabling those clients through electronic means to authorize the transfer of billions of dollars on a daily basis. The same controls, practices and principles that companies are already familiar with are translated into a broader context. You ensure responsibility at the company level so that it comes back to bite them if there’s a problem. You cannot administer a risk-based system without that.

On the other side, how does an application get engaged inside the Identrus system? Say an employee wants to cut corners or use a hardware security module for certificate storage. As the application becomes certified into the Identrus environment, the bank sponsoring that application bears responsibility for regular security checks.

Let’s go back to the smart card. How secure are smart cards? Could it be one of the weak links? Is a smart card more or less secure than keeping a certificate on a desktop or hard drive? No. As vulnerable as a smart card may be, storing a certificate in software has similar flaws. I can’t carry a hard drive around in my pocket. Again, if we ask what the certificate’s useful for, the answer is that it provides identity. The activation of the smart card does that. However, risk and liability take place when you’re engaging in a transaction. So we’ve created two certificates within our structure. One, a utility  certificate, establishes an SSL handshake. The other is an identity certificate—our signing certificate. That signing certificate is the liability-bearing certificate. You need a

passphrase to activate that signing, which binds the company to the transaction. If the smart card is in the reader, you’re not necessarily signing everything you do with your signature card. It’s only when the smart card is invoked or you’re asked to sign things from the application you’re interfacing with. We believe there will be various rules databases driving applications that will say, for example, ‘This is a normal interface, it’s low risk, so let the utility certificate govern.’ The minute I engage, it asks for a user response.

You’re requiring a very high level of compliance from users to maintain policies and procedures. Do you provide professional services to refine the security architecture of the enterprise?

Not directly, but through integration partners. Part of the certification process of Identrus is to certify bank deployments. No matter what their technology, we will have a robust set of security checks, which Identrus and our audit partners will ensure are in place.

We also have audit guidelines for banks and require banks to have similar checkpoints for their corporate installations. We’re raising the bar of consciousness, but we have to weigh security issues against commercialization issues. If we do nothing but mandate audit after audit, we will not have a robust or scalable solution. Security begins and ends with policies and procedures.

Originally appeared in the April 2000 issue of Information Security Magazine ( Copyright (c) 2000. All rights reserved.

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: