Monthly Archives: January 2013

Transport Layer Security ( use of TLS in SSL or HTTPS etc ) is a clear prerequisite for B2B eCommerce irrespective of industry. Without TLS eCommerce partners would not be able to trust who they are doing business with. You seldom ( perhaps never ) get something for nothing, and there is quite a substantial overall cost incurred in having to achieve TLS. I realized just how much effort managing trusted material was when confronted with an expired certificate for my OpenSource project demonstration protobuf-rpc-pro. Furthermore in my job in enterprise application integration i’ve experienced many real problems associated with the (mis)management of trusted material. Here some thoughts about the cost for medium to large sized organizations.

  • key generation and certification requests. This business function should only be performed by a security specialist, making the function expensive. Even if the cost of the certificate which verifies a public key is zero ( which it isn’t except for self signed certs ), this business function is expensive due to it’s specialization. There is an enormous amount of security knowledge required to use the tools ( openssl, keytool etc ), produce the right keys ( is 1024 bits ok or 2048?) and request the right kind of certification etc. Outsourcing of this business function is not advisable – considering this would equate to putting an organizations most trusted material into untrusted ( or not sufficiently trusted ) hands.
  • protecting the secret key. Wherever a private key is created or stored, it leaves a digital fingerprint ( even after deleting on a hard drive etc). This key generation function should be centralized to limit the risk of unintentional key loss or poliferation, and imposing a policy of using keystore passwords to protect private keys. There is a cost to the organization in educating anyone who deals with secret key material, even if it is just to explain the internal security policies – like not emailing keys to the places that they’re needed.
  • lifecycle management of trusted material. If a HTTPS certificate for a domain that you own expires, clients which rightly expect a valid certificate on connecting to your domain servers will no longer work. This puts a responsibility on the organization owning the domain to manage it’s certificates. Clearly when the number of certificates are large, this becomes a constant operational cost. The cost of replacing the trusted material ( keys & certificates ) on the webservers in a timely manner is only marginal. To run a cluster of webservers, requires a high degree of automation just to manage “routine” security patching and upgrades ( which should happen more frequently than key changes). A much higher cost is associated with informing partners about certificate changes which are likely to break their client’s current trust schemes. Clients’ trust doesn’t necessarily break, but it can be that new certification authorities are used which older clients do not trust, or new key lengths are introduced where older clients cannot use. In this case, if the partner management is not well managed, unlucky clients will only realize that something has changed when nothing is working and someone’s loosing money or customers. Knowing when clients will be affected by certificate changes is again a specialist function. Turning the perspective around, anywhere where your organization is a B2B client, you will need to manage constant certificate changes initiated by partners, and proactively realize which partners are obliged to replace certificates due to pending expiry.

Unfortunately use of TLS is not optional – not only for B2B commerce – but also within the borders of any organization, where the privacy and confidentiality of data transferred needs guaranteeing, and different parts of the organization ( employees / systems ) are trusted to different extents.

A couple of weeks ago i made a open statement at work to the effect that

“transparency would help to provide trust”.

I believed this statement to be true, even though i didn’t know why this should be the case, maybe it was just “common sense” to me. The spirit of my blog’s title is – “if you think you understood something – you probably haven’t”, so i wanted to understand why this statement should be true, not just my (possibly ignorant) opinion. An obvious example of how transparency helps provide trust is in the Open-Source development community. Almost without exception, Open Projects have full transparency into what the current and past “defects” affecting the product are. The use of bug tracking software like “Jira”, or inherent in the project hosting solutions, provide not only distributed team working utility to developers fixing bugs, but also trust to the users of the software. Through transparency of all bugs past and present, a user can judge the “stability” or “maturity” of the software, determine the project’s “health”, ascertain how many active developers support the software etc. Transparency here clearly helps provide trust – even if “what” is trusted is negative – like i’m sure the project id dead – so i’m not going to use it.

Now i used my initial statement about trust helping provide trust in the context of a company selling a commercial product. For a company selling product, trust between the customer and the company is a highly valued “thing”. Without trust, the initial sale would not have come to be in the first place. For an established customer base, loosing trust will eventually result in customer churn. So a question would be: would providing customers with transparency about what the company knows are the product’s problems help improve customer satisfaction, or just drive them away?

First we take a definition of trust from one of the many specific formulations of the abstract model of what trust defined in Dr. Ed Gerck’s Toward Real-World Models of Trust: Reliance on Received Information paper.

If you think you have understood what “trust” is – and you haven’t read Ed Gerck’s paper, then you most probably haven’t understood trust. This paper’s significance to me, is like Albert Einsteins theory of special and general relativity to Physicists.

  • “Trust is that which an observer can rely upon to some known extent regarding a subject matter”
  • Trust is subjective.
  • Trust is NOT transparency.

In the context of a company being transparent about known problems, the truster ( or observer ) is the customer. The “Entity” which is being trusted on some matter is the company. What is being trusted  is more complex. Potentially what the company is saying is believed ( why would a company state it’s product’s problems openly if they weren’t true?),  but more importantly it is the fact that the company is open about problems that is helping the customer consider the company trustworthy – which will affect future decision making. Transparency is feeding the “estimator” in everyone’s head, which will definitely be used to predict the behavior of the company on some matter in the future…..