Social Implications of Keysigning

[This was originally published on attrition.org. It was written by Raven and Jericho. A Bulgarian translation was done.]

Intro

The use of strong public encryption has always been popular among geeks. Perhaps the most commonly used and most beloved encryption for e-mail is Pretty Good Privacy (PGP); started as a free method for protecting emails or other sensitive information, later turned into a cornerstone for a large company. As PGP became more corporate, costly and used patented algorithms, another project, GnuPG, sprung up to continue to offer strong encryption to the masses.

One foundation of reliable encryption is trust. The use of encryption between two or more people relies on you being sure that the message you sent is properly encrypted to and able to be decrypted solely by the intended recipient. When using a friend’s GPG key, you must be sure that the key was created by and belongs solely to your friend. Otherwise, you may send mail that your friend cannot read (if they don’t have the key you encrypted to), or worse, mail that some other party can read (if that party does have the key you encrypted to).

Background

When exchanging encryption keys, establishing identity or verifying trust, there are multiple methods available. For casual conversation with a friend that has a new ICQ or AIM ID, this may be as simple as sharing an inside joke that only the two of you would understand. If the line of communication is more serious then a phone call, fax, or snail mail can be used to further verify the sender is who you believe it to be. Another method developed to help establish the trust of encryption keys and identity is known as keysigning. Quoting the GnuPG Keysigning Party HOWTO:

1.2 What is key signing?

Key signing is act of digitally signing a public key and a userid packet which is attached to that key. Key signing is done to verify that a given user id and public key really do belong to the entity that appears to own the key and who is represented by the user id packet.

You can digitally sign your own public key and an associated id on that key, or another entity’s public key and associated public key packet.

In a sense, key signatures validate public keys.

In recent years, keysigning parties have become more and more popular. Many security conventions have hosted keysigning parties that allow everyone to gather in one place, verify identity, and sign each other’s keys on the spot. Conventions like Black Hat Briefings and Defcon still host such gatherings while conferences like Usenix will no longer offer keysigning service. While Usenix conferences will still offer keysigning sessions, their choice to drop this activity lies with technical and managerial decisions, not reasons outlined in this article.

Foundation of Trust

The keysigning protocol is based on multiple levels of trust that can be illustrated by a fictional example with two persons of interest. The well known hacker/security conference ‘ImaCon’ draws a mix of people from all aspects of the security world. Attending this year are Raven and John E. Richo who have never met, but had occasional dialogue via e-mail and extensive communication via jabber. They plan to meet in person at Lyger’s Pub to discuss some ideas for security research in person.

After meeting and talking, they end the night by digitally signing each other’s GPG keys for future secure communication, establish backup methods for contact, and go their separate ways. During the convention, both have their key signed by a variety of other people ranging from casual friends to business aquaintances. The convention ends without the destruction of the hotel and everyone leaves knowing more about their profession than they did days before. Months go by before Raven receives a peculiar e-mail from John asking about work they had discussed extensively months before. A few confused e-mails and one phone call later, both are stunned when John learns that Raven signed ‘his’ GPG key, despite John never having used GPG.

Almost a year before, someone pretending to be John had intercepted and replied to a few e-mails of Raven’s. Unsure of his ability to keep intercepting the mail, he quickly suggested they move discussion to jabber and created a new ID to keep up the appearance of John. Months of chatting and an enjoyable night of drinks and discussion later, a deep sense of trust had been established between the two, and John never really entered the picture at all. Even with ‘his’ name, supposed phone number, pictures and more, the trust was built up slowly and steadily.

By the end of this trust building, the person who had hijacked John’s identity was able to get Raven (and others) to sign his key with high certainty that he was the real John E. Richo. Once that key was distributed to keyservers around the world, the potential for harm was strong. John’s digital identity had in effect been hijacked.

Issues

The information disclosed by the key signatures you receive may sometimes have unintended consequences. While not a serious issue to many people using PGP/GPG, this may manifest itself into situations of information disclosure that you may not be aware of. With the rise of social networks such as Orkut and friendster there is clearly interest and potential value in identifying and aligning yourself with social circles. For most people this is not a concern as it offers no downside or repercussions. For some, it could present a serious issue down the road including hurting credibility (regardless of social circle), disclosing social patterns offline such as meetings that were not announced, disclosing approximate geographical location and more.

There are a few basic truths to the use of PGP/GPG keysigning that one must consider.

  1. Individuals choose what name and email address are attached to keys. Some people use it in a professional capacity and as such have their legal name and work address attached. Other people may use it in a personal capacity, including individuals that wish to hide information for personal reasons such as a fundamental desire for privacy, to hide questionable material or legal reasons.
  2. Many people don’t want their legal identity attached to their key. How then does “Raven” or “Jericho” prove who they are? Handles do not lend themselves well to the protocol and typically add extra hurdles in establishing trust. Despite that, over half the people we know use handles instead of legal names for their keys.
  3. In the most simple terms, signing someone else’s PGP/GPG key establishes a tie between you and that person. The strength of this tie is not generally known from the signature and any assumptions about the ties are just that… assumptions.
  4. One strength and value of public key cryptography is the ability to make your key available to anyone and everyone, often via e-mail footers, web pages or public key servers.
  5. You have little to no control over who signs your key.

Social Network Mapping

By examining a person’s key and taking it one step farther, you can create a list of people that have presumably interacted with them. Following the links and checking other people’s keys will link to more people, allowing you to form a crude mapping of these links. Once you follow enough links and connect the people, interesting groupings may begin to appear.

From this example of a signed key link chart, a couple groupings begin to emerge showing the beginnings of social circles. In conjunction with browsing web pages, focused searches and a little common sense, it is possible to start making some logical guesses about social interaction, trust and other points of interest. With this diagram, we can observe the following and make a few guesses:

  1. The grouping around Jericho are mostly other attrition staff/volunteers
  2. Jericho/Forno run machines on the same network, likely they have met or live(d) in the same area
  3. Sullo/Jake/Jericho link to each other, the three primary names attached to the OSF/OSVDB
  4. Jake’s only other links are to real names. The e-mail addresses attached to those keys show where he likely works
  5. Forno/Jericho share common friends, may indicate a social club, mail list or informal grouping
  6. Greg links to an odd key that is connected to a government agency
  7. Raven may volunteer for OSF/OSVDB based on the link to Jake and advocacy for open source projects
  8. Raven’s social circle is segregated from the few links she has, suggesting division between personal and professional/technical friends

While all of these conclusions are logical, they rely on additional research above and beyond key linking, and they are all speculation. It is often difficult to establish if a link is personal or professional or both. The use of nicknames and handles on the net is not strictly limited to the darker side of things. Due to the nature of instant messenger software and e-mail services, there is significant encouragement to use a nickname or variations on just a first name. Add to that the fascination with adding a sense of mystery or intrique, and Bob becomes bowman14 while Jill becomes v1xen. Both may work at the same office, live very straight lives and never consider anything shady or questionable. Yet both have handles and may use encryption for work sensitive material.

Tarnishing Reputation

The good part about public key cryptography is that you can share your key with the world to be signed and validated. The bad part about public key cryptography is that you can share your key with the world to be signed and stamped. Since you can’t prevent someone from signing your key and uploading their signature, you can’t stop bad people from associating themselves with you and fronting some level of trust, even if it isn’t present. In this context, the bad people are those who don’t like you and may seek to discredit you, nothing more.

As a hacker, your word and your reputation are important. Without trust and/or technical skill, other hackers won’t share information or tools with you. As a clean-cut chief security officer, your reputation and ethics make up your integrity, and your integrity helps to sell you to your employer. If the hacker or CSO were discovered to have ties to the ‘wrong’ people, it could severely hamper their ability to do their job. Imagine if the hacker suddenly had his public key signed by a dozen law enforcement officers and the CSO found his key flooded with questionable hacker signings. Sound improbable or pointless? It isn’t. This type of virtual smear campaign has already been used against people in the security industry and by law enforcement to cast doubt on the reputation of hackers, with some success. Alienating someone via perceived reputation and ‘guilt by association’ are powerful weapons. Once done, you are essentially stuck with the virtual baggage until you revoke your key and cut a new one.

Beyond the Virtual Divide

The nature of PGP/GPG and keysigning is to maintain a system for digital trust. While some of that trust may derive from activity or history that originates offline, the primary purpose is maintaining privacy and security in communication online. As such, having that system potentially reveal information that transcends into the real world is a potentially serious threat.

When a keysigning occurs, it is typically done under a high level of trust. Such trust often occurs when two people meet face to face, leaving little doubt as to who the key belongs to. With the internet being a global entity, it isn’t easy for two people to meet just to sign each other’s encryption keys. This lead to organized meetings, typically targets of opportunity, where many people would gather to sign each other’s keys while participating in another event such as a technical conference. Some of the bigger conferences will host keysigning parties that number in the hundreds. These events are well established, well known and a matter of public record. Obviously, if you sign someone’s key while a conference is going on, it is fairly safe to assume that you were present.

Branch out a bit, and begin to track the keysignings of entire circles of friends, taking particular note of the timestamps of each signature. If you notice one key was signed by a dozen people on a given date, and received no signatures for a month before or after, it is likely he was in the company of many people on that date. Does it correspond with any well known events such as security conferences or 2600/B411 meetings?

From our example analysis above, we can see routine key signings throughout the year. The first small spike in January may correspond with a smaller meeting such as 2600, B411 or DC Groups. Jump to mid April and the big spike happens to correspond with the yearly AttCon held in Denver. In August we see another big spike that corresponds with the yearly Blackhat/Defcon conferences. In December, there is another big spike but doesn’t match any public conferences that we can find. What happened during that time to warrant so many key signatures? This could be indicative of a private conference/gathering? Perhaps some other type of meeting such as a Linux user group (LUG), USENIX meeting or NANOG keysigning? Or something else of interest.. does this correspond with a law enforcement seminar at Quantico or a regional Electronic Crimes Task Force meeting?

Continuing the data mining, it becomes easy to use Google to figure out a little bit about a person. Add that data to where they likely traveled based on key signatures, and you have a good foundation for mapping their travel, social circles, business colleagues and more.

Split Personality

For those that opt to walk the line between black and white hat, or comfortably live in the colorful world of the grey hat, they may choose to maintain multiple keys. One may be kept under their long time alias while another maintained under their real name for business purposes. If the masses do not know that ‘Jericho’ is the same person as ‘Brian’, it behooves me to keep the identities separate. Maintaining this separation is technically easy, but often difficult as the human nature tends to forget about the separation. All it takes is one slip up and it can become trivial to link two distinct personalities to the same person.

Encryption keys are one of many avenues to help you figure out if different personalities are really the same individual. When examining the signatures on a key, consider that a good friend may sign both of your keys. Alone, this means that the person seems to know and trust two separate people.

Raven -> Jericho
Raven -> Brian

If the same thing occurs with a dozen people, it may be a bit suspicious. Consider two keys from what are assumed to be two separate people (Jericho and Brian) that share twelve out of fifteen signatures. Jericho’s key has three signatures all from people operating under an alias. Brian’s key has three signatures all from people operating under their full legal name. Even with the three key signature discrepancy, it is safe to assume these two people run in the same circles and may very likely be the same person operating under two identities. Add in the previous data analysis and notice that the signatures all occured on dates that show they were in the same places at the same time, and it becomes more and more probable that you have cross linked a real name to an alias.

Conclusion

While the social implications of PGP keysigning are not as groundbreaking or sexy as cracking strong encryption, the nature of these risks tend to have a significant impact none the less. Passive information disclosure via social networking analysis is not a new concept. Just recently the National Security Agency was found to be using millions of phone records for social networking analysis. This type of data mining is not new by any means, but the analysis of different data is leading to more advanced relationship modeling that can pose a serious threat to your privacy. By all means, continue to use strong encryption to protect your communication. Just do so with the knowledge that your security may lead to insecurity.

For Example…

[This was originally published on the OSVDB blog.]

Did you know that RFC 2606 provides for the Internet Assigned Numbers Authority (IANA) to reserve several top level domains, as well as three second level domains in order to provide a safe domain name? To avoid conflict and confusion the domains example.com, example.net and example.org are all reserved so that professionals can use them for private testing, examples in documentation, DNS experiments and other uses.

This is a good thing for IANA to do, and something that security researchers should be aware of. Currently, we see hundreds of disclosures each month use other “example” type domains, many of which point to real sites. This is a bad thing as it can cause a world of annoyance and potential harm to these sites. Think about hundreds of sites that mirror Bugtraq or Full-Disclosure, and all of the search engines, web bots, and spiders that follow all links without bias. Each time they encounter http://example.com/hi.txt, they try to follow it. For those who follow the guidelines in RFC 2606, this is acceptable and no one really gets harmed. For those using other domains, you may be causing additional traffic (often with exploit like code/requests) to sites that shouldn’t receive it, even if using 127.0.0.1 or other reserved internal IP addresses. OSVDB goes one step farther by using [target] and [attacker] to designate examples. This is done for consistency of course, and yes I realize some older entries don’t follow that guideline, but also on the off chance that some wiley hacker type doesn’t decide to screw with DNS servers. What happens when tomorrow, dozens of high traffic DNS servers start pointing example.com to [target].com?

In just the last couple of months, we see examples of the advertising site www.vuln.com, Site Services Inc.’s www.site.com, the non-existant host_evil.com, the broken web site of www.anysite.com, a possibly ironicly defaced web site of www.vulnerablesite.com, the adult content laden site www.XXX.com, the large corporate retail store www.target.com, and the domain squatted attacker.com are all used as example domains for exploits. Every day that a web spider or search engine goes crawling, odds are these sites get some odd traffic. If they run intrusion detection systems, i’d hate to be the one tasked to monitor them.

The most amusing of this list is probably victim.com which contains a quote and link to a published exploit in which a lack of following RFC 2606 may have lead to one person’s frustration, and this resulting site.

Why I’m So Behind

[This was originally published on the OSVDB blog.]

Another night of working on OSVDB, mainly focusing on vulnerability import and creating our entries to cover issues. Most nights end with between 25 and 50 new entries and a feeling of accomplishment. Well, other manglers can see the accomplishment if they check the back end, and that gives a little positive reinforcement. On really big days I just spam the status line to Jake and Sullo and demand instant gratification and the promise of booze to dull the pain.

Anyway, tonight was productive but no one but me and Speedbump will realize. I can thank IBM and a set of ridiculously large changelogs full of mind-numbing poorly written bug reports and excessive (apparent) duplication of entries. It started out with a simple Bugtraq post about some vulnerabilities in IBM WebSphere Application Server. First off, I find it quite amusing that people are now taking credit for merely posting vulnerability information culled from another source.

Provided and/or discovered by:
Reported by the vendor

Reported by SnoB

If this type of activity deserved merit, VDBs like Secunia, CVE and OSVDB would be virtual gods of vulnerability disclosure. Second, he lists seven issues from a changelog that contains hundreds. If you go dig through the changelogs like the one for the Fix List for WebSphere Application Server Version 5.1.1, you may find more of interest. While browsing them, I noticed a fairly insignificant but ironic characteristic of the way IBM handles these disclosures. If you want to read the list of over five hundred entries and only pick out the security related ones, you can! Skim the list for any P##### number that doesn’t hyper-link to another document. 95% of the time, these are security related. So while IBM is not providing additional details about these issues (security through obscurity), they are making it easier to pick out which entries are of interest.

Oh yes, back to the exciting night life. After checking the latest list of changes as well as digging into some past fix lists, I ended up with around 75 more vulnerabilities, most of which are not in our database (or others). This list I extracted has some dupes in it, meaning the same issue affected multiple products or version lines. However, it is quite curious to see the same vulnerability patched half a dozen times over two years across many versions. Is IBM reintroducing the same vulnerability back into the code over and over? Or are they following the Oracle method of mitigation and not looking at the bigger picture and fixing similar vulnerabilities in the same code? Anyway, since I know I won’t get an answer to that, consider that it would take you twenty or more hours to read and digest a handful of these fix lists, and in doing so, you would likely find fifty or more vulnerabilities above and beyond what I found. The amount of information is overwhelming to say the least.