Authentication Beyond the "Norm"

A week of vacation always gives one time to do some extra reading - catching up on things and looking at a broader base of things. This past week I had that opportunity and a theme came through in some of the articles I stumbled upon ... Authentication is generally thought of as a person authenticating to an application or two applications authenticating to allow processing of data. However there are other things that we need to keep in mind when we think of authentication.

Some of the major issues that are now being encountered are centering around source of base technology. Malicious code embedded in devices manufactured in other countries is one example. To date we have seen this method leveraged in devices used within the power grid and this has also been seen within components in laptops. This type of extended attack is much deeper and worrisome for many as it can go undetected for many years before being launched. Within the software application environment we of course have code signing that is intended to mitigate the similar style of attack which has been seen through code delivery. Code signing itself cannot stop the attacks that are further embedded in the base technology and to some extent does not mitigate all software based code attacks. There is a need in both environments to design a more complete end to end protection of systems.

Part of the issue in design of such systems comes to ensuring compliance in an environment where base technology is being delivered from many sources and in many cases to a consumer that is first concerned with immediate technological gratification - how many of us click through user agreements before installing software? Certainly there is an attempt at resolution here with the Trusted Computing Group's platform approach but broad acceptance of this across the many technology platforms has not happened.

So how do consumers and users protect themselves? That may be the muti-billion dollar question. Certainly there are simple things to mitigate risk for a consumer:

- Where possible buy a platform with a TPM (Trusted Platform Module)
- Only execute signed code
- Ensure proper validation options are turned on (CRL/Revocation Status checking for example)

The broader answer is something like TC. Is it signed object code? But how do you validate that code? Who authorizes the signature? Certainly there are many more questions and solutions but it is a problem that is growing and it will take a cooperative solution between hardware technology manufacturers, software distribution companies and software developers at a minimum. Education for the consumer is also important and something that has to be considered.

Maybe initiatives like NSTIC will get the conversation going - that would at least be a start.