TSA Master Keys, or: How security through obscurity will hurt you

September 30, 2015
Info notes


The United States Transport Security Authority (TSA) has the authority to open any luggage passing through the USA for security screening. This authority extends to breaking any locks that would prevent the luggage from opening. Travellers who want to lock their luggage, but would rather avoid seeing their locks broken by the TSA, can use TSA-approved locks, also called "Travel Sentry" locks. TSA agents have master keys that allows them to unlock and re-lock these locks.

Following a set of events that led to the exposure of the master keys, the security of Travel Sentry locks is now completely compromised.

The facts

Almost a year ago, the Washington Post published an article on luggage handling and screening at the Baltimore-Washington International airport. The article went unnoticed in the security community until late August, when a blogger mentioned (https://www.lawfareblog.com/tale-three-backdoors) that by combining the high resolution picture of the TSA Travel Sentry master keys included in the article and a paper published by UCSD researchers anyone with the right tools could replicate these master keys.

The right tools used to be costly and hard to obtain. This is no longer the case: several people managed to replicate the keys on readily-available 3D printers, and have made the instructions public. Anyone can now print a master key, and open TSA-approved luggage locks.

All the security resided in the secrecy of the keys' pattern. Now that the cat is out of the proverbial bag, there is no way to cheaply replace the millions of locks that are in circulation. This is a typical example of security through obscurity: it is the belief that the lack of knowledge of the inner workings of a security system will prevent its compromise.

The Information Security angle

Below are some common examples where security through obscurity occurs in ICT:

  • System administrators protect an administration interface by hiding it on an uncommon port, but do not change the default password or encrypt the communication. This approach does not protect anything, because a quick port scan will uncover the hidden administration interface. It is then not more difficult to sniff the traffic, or use the default password to get in.
  • Software developers encrypt communications using a hard-coded key. It takes one attacker with the skills to reverse engineer the encryption key and make it public for anyone to be able to decrypt a secret communication.
  • SOHO routers include a hidden user with administrative privileges and a fixed password. Once again, when someone with the relevant skills makes these credentials public, everyone can use it to gain administrator rights.

Security through obscurity alone only gives the illusion of security. It lures users into thinking they are safe, while they are in fact very much exposed. It hurts security.

Conclusion and recommendations

Security through obscurity is not security. It provides a false sense of security which is often more harmful than not addressing security at all. If used at all, it should be with caution and only as an additional measure, as in the following way:

  • Hide an encrypted and strongly authenticated administration interface on an uncommon port. The real protection comes from the encryption and authentication, but the added obscurity can help by filtering background noise and revealing suspicious activities on this port.

Everyone, from systems administrators to systems designers and end users should avoid security through obscurity. If used, it must be a conscious decision, and as an additional layer of protection, on top of measures like encryption, strong authentication, and systems hardening.

The opposite of security through obscurity is security through transparency. Systems should be secure even if attackers know all the design or algorithms. The best example resides in the good design of cryptographic algorithms, where the only secrets are the keys, and the attacker is supposed to have access to everything else.

About “Info Notes” from ENISA

With the “Info Notes” series ENISA aims at giving the interested reader some background and recommendations about NIS related topics. The background and recommendations are derived from past experiences and common sense, and should be taken as starting points for discussions on possible course of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more information on the “Info Notes” series (cert-relations@enisa.europa.eu).

We use cookies on our website to support technical features that enhance your user experience.
We also use analytics. To opt-out from analytics, click for more information.

I've read it More information