TRUST (AND MISTRUST) IN SECURE APPLICATIONS.(Industry Trend or Event)

Exploring and considering trust assumptions during every stage of software development.

TRUST AND TRUSTWORTHINESS are the foundations of security. Homeowners trust lock manufacturers to create quality locks to protect their homes. Some locks are trustworthy; others are not. Businesses trust security guards to admit only authorized personnel into sensitive areas. Some security guards should be trusted; some should not. CGI programmers trust users to provide valid inputs to the data fields on Web pages. Although most users can be trusted, some cannot. The basis for these trust relationships and how they are formed can dramatically affect the underlying security of any system--be it home protection or online privacy.

Because these trust assumptions are often illusive, software development efforts seldom handle these assumptions correctly. Several common ways in which erroneous trust assumptions in software applications can wreak havoc on the security of those applications are explored here. We consider the common trust assumptions and why they are often wrong, how these trust assumptions can arise during an application's development process, and how to minimize the number of problematic trust assumptions in an application.

A trust relationship is a relationship involving multiple entities (such as companies, people, or software components). Entities in a relationship trust each other to have or not have certain properties (the so-called trust assumptions). If the trusted entities satisfy these properties, then they are trustworthy. Unfortunately, because these properties are seldom explicitly defined, misguided trust relationships in software applications are not uncommon.

Software developers have trust relationships during every stage of software development. Before a software project is conceived, there are business and personal trust relationships that developers generally assume will not be abused. For example, many corporations trust that their employees will not attack the information systems of the company. Because of this trust, a company might have a software application talking to a database over the company's network without the aid of encryption and authentication. Employees could easily abuse the lack of security to convince database applications to run phony updates. Companies usually trust their software developers and assume their developers will not leave back doors or other artifacts in their code that could potentially compromise the security of the system.

System architects must constantly deal with trust issues during an application's design cycle. Proprietary design documents and other data are often communicated over channels that should not be trusted (such as the Internet); the developer must weigh his or her trust in the people who might have access to this data, along with the potential consequences of those people abusing that trust.

Often, designers make trust decisions without realizing that trust is actually an issue. For example, it is common for a client application to establish an encrypted session with an application server using a hard-coded symmetric cryptographic key embedded in the client binary. In such a situation, many developers fail to realize they are implicitly trusting users (and potential attackers) not to reverse-engineer the software.