Blogsig Update – Embedding Information In A PGP Key

My implementation of a message authentication scheme for blog and Internet forum posts is designed to utilize the existing PGP key server infrastructure. The first proof-of-concept code embedded the EC key used by blogsig in the ‘Comments’ field of a PGP key. This was functional but far from sensible given the other options available.

The OpenPGP key format was designed with adaptability in mind. A feature which is commonly used to embed an image of the individual within the public key (likely inspired by the popular use of the X-Face header to embed an image of a user within newsgroup and email posts in the 90s) is also suitable for our purposes.

RFC4880 describes the “User Attribute Packet” and its primary use. It also states that packet type ‘1’ is a JPEG image, whilst types 100-110 are reserved for private or experimental use.

The next task I have at hand is to confirm that the key servers will not strip packets of an unknown type from a key. If this test is successful, I will use a packet type that does not conflict with any existing projects to denote a blogsig EC public key and this will become the standard means of embedding a blogsig public key within a PGP key.

Using the PGP key servers makes a lot of sense as we don’t need to setup our own infrastructure for blogsig. The primary identifier given in every blogsig signature line appended to posts is the PGP key ID. We’ll see how this concept works out. A full specification and example code will be published once all the details have been fully tested and hashed out.

We expect browser plugins to make the entire blogsig process transparent. I’ve gone to great pains to ensure that the blogsig itself does not exceed 80 characters (one standard line) in the worst case scenario in order to make something that is usable and uninstrusive on Internet forums. Depending on the blog’s policies the signature could even be hidden in an <a> tag.


Robert Graham of Errata Security recently wrote in a blog post that over 300,000 hosts are still vulnerable to the OpenSSL heartbleed bug and posited that people had stopped even trying to patch.

While disconcerting, I imagine that a significant portion of the ~300k reported are embedded systems and that sysadmins are likely aware of the issue but effectively have their hands tied until their vendors submit a patch. Given that many consumer devices like DSL CPE’s are seldom updated, and many ISPs make the mistake of leaving remote administration open without even applying basic security hygeine practices like IP filtering to only their internal networks, I assume that these problems won’t be solved any time soon. Heck, there are still routers affected by the d-link hardcoded administrative password vulnerability that remain accessible.


The US House of Representatives today passed an amendment that will see NSA programs designed to introduce backdoors are no longer funded. The bipartisan agreement, entitled ‘Massie-Lofgren’ was billed as an exciting development by the EFF, with Mark Rumold – the Foundation’s counsel stating that they “applaud the House for taking this important first step, and we look forward to other elected officials standing up for our right to privacy.” Many, including myself, have questioned as to whether the new bill will truly be effective in curtailing the NSA’s spying – at least on the domestic front. I suspect that it will be business as usual for the NSA and their associated contractors and affiliates.

An Update On Blogsig – RFC Due Within The Week

I am pleased to announce that the technical standards documentation for blogsig: a message authentication system for Internet forums will be made available on this blog within the next few days. Development on the proof-of-concept remains fast paced, and the standards document appears to be quite a living and breathing thing with modifications being made daily. As regular readers of this blog will know, I have spent a considerable amount of time engineering blogsig – a simple message authentication system for Internet forum posts that augments, rather than replaces ‘stronger’ technologies like PGP.

The blogsig extension enables in-browser verification of posts.

The blogsig extension enables in-browser verification of posts.

A flow chart documents the validation process from the perspective of the browser plugin.

A flow chart documents the validation process from the perspective of the browser plugin.

Today you will notice that I have put up a somewhat simplified flow chart showing how a browser plugin designed to validate blogsigs would go about the verification process. There are some critical parts missing from the chart and it isn’t intended to be an entireley accurate representation.

The project has unfortunately been sitting on the back burner for a month or so due to work and family commitments, but now the specification document is nearing completion and the demonstration code is also not too far off being releasable. Some final decisions on architecture still need to be made as my current system makes use of ECDSA and I’d ultimately like the finished product to use djb’s ED25519. So, stay tuned and I will upload the documents here for all to see and critique.

UPDATE: The flow diagram has been updated to reflect that data is now embedded within the PGP key as a User Attribute, rather than simply being put in the Comments field.

Another BMC Vulnerability

The good folks over at CARI SIRT have discovered a vulnerability in the BMC controller shipped with many Supermicro servers. The vulnerability essentially allows an attacker to connect to port 49152 and issue a GET request for a file called PSBlock, the plaintext passwd file for the service. Now, obviously given that most people know better than to leave IPMI or other management features publically accessible and most servers at the very least ship with the management controller bound to the secondary NIC (I believe Supermicro doesn’t have this sensible default set in the BIOS), so I would assume that most competent system administrators have quarantined the BMC feature within their management network.

That said, I have on several occasions opined about the danger of both IPMI on servers and Intel’s AMT on desktops – a danger that is not helped by the fact that many people aren’t even aware that their board has the feature in the first place. Of course, disabling any and all remote management features and requiring positive action (i.e. enabling IPMI, AMT and WoL manually on a BIOS setup page) to enable them would be the sensible thing for all vendors to implement given that there are large numbers of networks that don’t even use or even want the features and the risks they pose. There is patched BMC controller firmware image available from Supermicro’s website, but the CARI article indicates that as of writing there were potentially over 31k vulnerable devices publically scannable by Shodan.

Incentivizing Users To Ignore Security Advice

Bruce Schneier today shared an interesting link to a CMU study that attempted to discover whether users could be incentivized into running harmful code. In the linked article they mention the surprising statistics, and elucidate their experimental methods including virtual machine detection to identify security researchers/the computer savvy who would obviously not put their base OS at risk.

The results of the study prove that users can be trivially manipulated.

The results of the study prove that users can be trivially manipulated.

The study notes that ~70% of those studied were well aware of the dangers of executing unknown code. A staggering 22% of users proceeded to execute the code despite the remuneration being just one cent. Now that’s incredible. The authors summarize (and borrow from the paper’s title) that it is “all about the Benjamins” but given the amounts offered I believe it is unlikely that the financial incentive played that great a role. If you make anything interesting or novel, as this experiment did – then people will play along, just as marketers discovered years ago when they started making their promotions interactive. If people feel that they have to work to receive some arbitrary award then compliance would be even better. A great recent example of this was the Coke ‘Friendly Twist’ promotion where the company designed ‘trick’ bottles that could only be easily opened by locking the lid into that of another and dumped a refrigerator full of them at a college campus on the first day of the school. Ostensibly the advertisment stated that the first day of college for many is an awkward and isolating experience, and that through the magic of their novel piece of polyethylene the ice was broken. These kids will have lasting relationships, and it will all be thanks to the clever execs and PR folk at Coca-Cola.

We often focus a lot of attention on the technological side of securing our systems. We ensure that all un-necessary services have been shut down, make sure that those services we must run remain patched up, perform regular audits, run an intrusion detection and network monitoring system, configure remote logging to an immutable and append only medium, ad naseum. But what about the fools who already have legitimate access to your systems? How do we know that they haven’t decided to bring a USB stick full of trojan-laden warez into the building, or decided to write their credentials on a sticky note affixed to their office wall. Perhaps they are particularly stupid and have decided to connect their Pentium 4 era Windows XP laptop complete with Zeusbot (and white gunk between the keys on the keyboard, most noticeable near the T key, which has gone AWOL in protest against what could either be dandruff or low quality cocaine) onto your office network. Oh yes, you know the guy, down the hall in HR. He requested VPN access so he could telecommute and upper management went over your head and have asked you to make it happen as his 200# body exudes an odor that can only be referred to as offensive and his office is right near the air conditioning’s pickup.

Sure, you’ve tried to cover at least some of the human aspects. You’ve ran a memo around the office explaining about your IT Acceptable Use Policy and why opening that important looking “payroll.pdf.exe” isn’t such a good idea, and done your best using group policies to prevent people from doing the really stupid things that have already been considered. But you can’t lock everything down to the point of uselessness. Your attempt at implementing two factor authentication resulted in people just hiding their smartcards under their keyboards. People don’t like being inconvenienced by what they often see as un-necessary security theater. Because nobody is going to attack our business, right?

Our users are the weakest link, and the threat posed by rogue (and just stupid) employees is difficult to entirely mitigate. Many business applications make things worse by requiring privileges that they shouldn’t even need, further weakening an already flimsy defense. The simple fact is that most organizations have reasonable IT security to protect themselves from externally originating threats, but the true soft underbelly of the corporate network lies within the safety of the city wall. We can always do better – be more granular in access control, have behavioral based detection to identify users attempting risky behaviors, religiously adhere to the principle of least privilege and ensure that each user’s privileges are individualized to their requirements and that they have the bare minimum in privileges to do their job. This approach may make you unpopular around the water cooler, but a breach – especially a breach that exposes confidential data like customer credit card numbers and billing details to the world could potentially kill a smaller enterprise, and will undoubtedly do severe damage to the reputation of even the largest business on the block. Unfortunately, the majority of problems are between the keyboard and chair.