Friday, October 26, 2012

Sony's PS3 DRM Cracked

Anyone who pays any attention to DRM will extrapolate the general principle:
You can never prevent an end-user who has physical control of a device from breaking any DRM scheme you can invent.
Sony just learned their DRM lesson (again).  I'm sure that people at Sony already know this principle, but some "suit" tells the engineers to "do something about the problem" so they implement a technical speed bump. That's all it is and will ever be.

Thursday, October 18, 2012

Skeleton Keys

Wouldn't it be really scary if physical locks in large planned cities like NYC were designed to use skeleton keys-- master keys that are shared with do-gooder firefighters and locksmiths alike-- without ever thinking what could happen if such keys got into realm of the average Joe, whose do-gooder status was unknown?  Yep it would.

Look but don't pay attention to key teeth details!
Wouldn't it be even scarier if those who cried "the sky is falling, the sky is falling" also were dumb enough to post high res photos of the skeleton keys on their websites (pictured left) so that anyone with access to key blanks and tools could easily measure and create their own skeleton key copies?  Again, yes.

Saturday, October 13, 2012

Picking Handcuffs

Because you never know when you just might need to have this skill:

Saturday, October 6, 2012

Finally a Safe Hello World

It's very common for Hello World example apps in textbooks or other educational literature to promote insecure software building practices right out of the gate.  What a breath of fresh air to see the Microsoft MVC folks safely HTML encoding (to avoid XSS) in their MVC4 Hello World application!

Friday, October 5, 2012

Coping with Compromised Certificate Authorities

With the news containing stories of malware distributing via compromised Certificate Authorities, it makes sense that some IT Security blogs would address "what to do" if this happens to your CA.  This blog post gets it wrong, though:
What would you do if you found out that the Certificate Authority that provides Digital Certificates to your company was compromised, and Microsoft was adding the Certificate Authority’s public key to Windows un-trusted Root Store? Well if you have not got a contingency plan to implement then I can presume you will be in a panic to purchase new certificates from another Certificate Authority... It can take Certificate Authority’s (CA’s) a few days to validate domain ownership and company registration details... While all this is happening your customers are getting a message from Internet Explorer that your SSL certificate is not to be trusted.
What can you do?
  • Do not rely on one Certificate Authority for all of your certificates. You should have a relationship with at least two well known Certificate Authority’s and the CA’s should have validated all of your domains. This will let you quickly order Digital Certificates from the second CA without having to go through the company validation process...
  • If you cannot tolerate any downtime for a service you can take the extra step in which you create backup certificates for each service using your backup Certificate Authority. This will enable you to implement the backup certificates without having to contact the second CA and joining the queue of company’s looking for new certificates.
Keep in mind that the worst-case scenario described above would require the Root CA Certificate to be compromised.  Most Root CAs are offline certs, meaning the computers that house them are not powered on except during special circumstances when new intermediate CA certificates are generated, OR, they are online in an "air gap" (disconnected from the internet) network accessible only via sneakernet.  Exploiting an offline CA is a big deal, and if it occurs it won't be just your organization that is affected, but likely a large part of the entire internet.

So a much more plausible option:
  • The CA will just create a new intermediate CA cert and re-issue client certs to all of its paying customers.
In other words: nothing to see here, please move along.

Thursday, September 27, 2012

Vauban Star Fortifications

Bourtange Star Shaped Fort
Taking a blast from the past that still has some application in today's physical security landscape ...  Star Shaped Forts using the Vauban (military engineering) Principle.

Acute angles on the corners of a building are added to the architectural design to eliminate "dead zones" in which an adversary could hide or take refuge.  At the time of star shaped fortifications, all of the competing designs employed rounded towers or turrets at each corner, typically to house archers.  As a breaching force approached the rounded corner, they were able to hide from the archers using the fortifications intended to be an asset in favor of the defenders.

Acute angles, however, prevented the breaching force from seeking shelter along the very walls intended to shelter the defenders.  [See the illustration, below right.]

Modern applications against a well equipped modern adversary are very limited, since "air support" ruined traditional fort designs (adversaries can simply rain fire from above).  However, against a low tech insurgency, the classic star design still prevails.

There are also applications for the acute corners in modern civil architecture.

For example, an HVT (High Value Target) person, such as a celebrity, bank CEO, or anyone else that might typically employ a Private Security Detail, these corners help to deter snatch-and-grab and similar attacks by simply limiting the avenues of approach.  Col Jeff Cooper, famous for dealing with small arms fire, had a fascination with these acute angles to the extent that the term "Cooper Corners" was coined referring to this much older design.

In public civil architecture, there are obvious applications in places such as bank vaults, manufacturing facilities where the likelihood of espionage is high, and even public restrooms in semi-remote and semi-private, yet public places like city parks, where the likelihood of an after dark robbery or rape assault is high.  In the case of the park (along with a well designed layout of lighting, landscaping, and shrubbery) the acute angles may be just the trick to eliminate lie-in-wait hiding places.

The next time you are tasked with securing a high value asset at a physical location, being familiar with the acute angles of the Medieval star fort might be the exact tool you need to pull out of your security toolbox.

Wednesday, September 26, 2012

Avoiding Protests with a DIY Press Pass

Do you live in an area that is likely to have civil unrest and protests?  Perhaps having a Press Pass may get you out of trouble.  ITS Tactical ran an article on just how to do this.

An excerpt:
Protesting is About Attention! Use that to your advantage. Protesters love the press. It can be a relatively simple proposition to get a press pass that will get you through/past protests that completely block traffic. Afterwards, ask them for a letter stating you have written for them, etc.
  • Set up a blog using a free service like Blogger or WordPress.
  • Write an “About” page or article telling people that this blog is for covering local protests or demonstrations
  • Design your own press ID using a template (Here’s an example template). Don’t lie on the pass. It’s not necessary.
  • Print it on a solid plastic card. There are tons of companies that will do this for a few bucks. (Here are a few) I had mine printed locally for  about $.80 each.
  • Throw the ID on a lanyard or in an ID armband and stash it in the glove compartment for whenever you may need it.
  • If you have to use it, present it with authority!  It has never failed me, even under the scrutiny of armed soldiers at roadblocks.

Friday, September 21, 2012

Destroying Paper Documents

The folks over at ITS Tactical have an interesting article on securely disposing paper documents.

Here is an excerpt:


The reconstruction of sensitive documentation has been around as long as shredders have. According to a fantastic NY Time article that everyone should read, reconstruction was first brought to light during the 1979 US Embassy takeover in Tehran. The Iranians elicited the help of local carpet weavers to reconstruct sensitive documents, which were sold on the streets of Tehran as a testament to US imperialism.

Just know that with some time and even the help of computer programs like Unshredder, there isn’t much reassurance that your documents will stay shredded.

Document Burn Bag
ITS Tactical also sells "Burn Bags" for important documents (or shreddings from documents) at a reasonable price, just like the kind you'd find at government agencies or in the movies.

Tuesday, September 11, 2012

Lock Kill

Do you have a house/door key lock that you no longer want somebody to have the ability to unlock, but you don't have time to change the locks?  Maybe you're a landlord?  Or maybe you have some hidden purpose, such as forcing door traffic to a different entry to the building?

LockKill has a solution: a specialty key designed to slip in, bypass tumblers long enough to get all the way set, and then sheer off in place, destroying the lock.  It only takes a few seconds.

Warning: the only real way of bringing that lock back from the dead is to replace it.

Watch the review by ITS Tactical:

Saturday, September 8, 2012

Cognitive Side Channels

A recent media buzz this week involves so-called "side channel" attacks or leakages of information from human brain to computer interfaces.  Not a ubiquitous technology today, but quite possibly down the road.

Essentially the attacks follow the lines of showing a plugged-in subject a bank, in which case the subject's mind races down the neural paths for things like account numbers, PINs, maybe balances or recent expenditures, etc.  And the mere thoughts picked up by the device can capture these otherwise private thoughts inside the subject's brain.

Sound scary?  It is.  The brain wasn't designed to keep information from itself.  Count us out of the "early adopter program".

Reminds us of the time the Ghostbusters were told the worst thing they could think of would be their next enemy:

Friday, August 24, 2012

Protecting Cars from Viruses

Reuters is running a story that should amuse any computer security professional: Experts hope to shield cars from computer viruses.

An excerpt:

Intel's McAfee unit, which is best known for software that fights PC viruses, is one of a handful of firms that are looking to protect the dozens of tiny computers and electronic communications systems that are built into every modern car.

It's scary business. Security experts say that automakers have so far failed to adequately protect these systems, leaving them vulnerable to hacks by attackers looking to steal cars, eavesdrop on conversations, or even harm passengers by causing vehicles to crash.
Our guess is that when cars get to the point that they drive themselves, those who understand how malware works-- and more important: how undeniably complicated modern software and its hardware architecture can be-- will start donning a pair of Converse Chuck Taylors and resemble a modern Luddite by driving themselves, a la Will Smith in I, Robot.

When you look at the statistics, you are far more likely to get injured or die in a car accident than you are in nearly any other security risk you face in your daily life.  Even with the vast skies being what they are, and the regulations on the airlines industry and their pilots, it's not possible to keep air travel 100% safe, though it's safer than driving (once you get past the TSA checkpoint).

Computerized, self-driving cars may improve (emphasis on "may") safety stats; however, not if their software landscape looks like anything else we operate with a CPU in it these days.  There are agencies with an operating budget larger than the GDP of several nations that are terrified about the possibility of malware injected into things like military aircraft or missile guidance systems.  Given that, how in the world is an automobile for ~$20K (which is at most 1% of the price tag of the military's concerns) ever going to be 100% free of malware?  Simple: it won't be.
Toyota Motor Corp, the world's biggest automaker, said it was not aware of any hacking incidents on its cars.
"They're basically designed to change coding constantly. I won't say it's impossible to hack, but it's pretty close," said Toyota spokesman John Hanson. [emphasis ours]
Oh, we've never heard that before...

Officials with Hyundai Motor Co, Nissan Motor Co and Volkswagen AG said they could not immediately comment on the issue.

A spokesman for Honda Motor Co said that the Japanese automaker was studying the security of on-vehicle computer systems, but declined to discuss those efforts.
Mums the word is a much smarter response to the press.
A spokesman for the U.S. Department of Homeland Security declined to comment when asked how seriously the agency considers the risk that hackers could launch attacks on vehicles or say whether DHS had learned of any such incidents.
They probably declined to comment because they are working on exploits for these as well.  Say it ain't so?  Look no further than Stuxnet and Flame, of which the US Gov takes full authorship credits.  It's the future of the "cyberwarfarestate".

We can't keep malware out of critical infrastructure SCADA systems.  There's no way we can keep it out of your mom's minivan.

Thursday, August 16, 2012

Classic Trust

Ken Thompson is on the left. That's not Adam Savage on the right.
If you work in computer security or software development, and you have never read Unix co-creator Ken Thompson's original 1984 speech "Reflections on Trusting Trust" then you are hereby obliged to at least read the following snippet for today's history lesson, which is just as relevant-- actually more so-- today:
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
Ken was referring to the trojan modifications he embedded into the C compiler, illustrating that you need to rely on more that source code, but the compiler, the assember, the loader, all the way down to the instruction sets of the CPUs.  Or as Schneier famously pitched: "security is a chain; only as strong as its weakest link".

Who operates on a completely self-built system from software to hardware?  We would venture to say: nary a soul.

Just a good reminder for a random Thursday, in case you forgot.

Monday, August 13, 2012

Hacking Hotels

Breaking into a hotel room with less than $50 in hardware
The technical security media has been all abuzz about a recent Black Hat presentation by Cody Brocious on hacking electronic hotel door locks.

The original author's documentation including the paper and slides are here.

Here's the simplified version:
  • The vendor of the locks has an overwhelming majority of the market in the U.S. (chances are you stayed in a room that had this exact lock on it)
  • The key cards use crypto for implementing the access control
  • The mathematical aspect of the crypto is more or less fine (as is usually the case)
  • The problem comes in managing keys (which is pretty much always the problem!)
  • An administrative feature is easily exploited-- which is only slightly better than vendors shipping products with widely-known default passwords.
  • An administrative maintenance device, when connected, can extract the crypto key and break the access control
  • You can roll-you-own maintenance device on the very, very cheap
  • Yes, this probably looks like a scene in any random Hollywood movie
  • This will likely be a majorly expensive pain to fix for the vendor and hotels
  • "Compensating controls" in this case include surveillance cameras, internal dead bolt manual locks, et al

Wednesday, August 8, 2012

MS-CHAPv2 Crack

It should come as no real surprise: MS-CHAPv2 is broken.  It's an ancient scheme.  If you were paying attention, you would have migrated your VPNs and Wireless networks away from it years ago anyway.

Here's a great break down of what this means to your wireless networks.

An even simpler one is to just note that these combinations are still fine:
  • IPSEC and OpenVPNs are fine.
  • WPA2 Enterprise wireless with PEAP is fine.
  • WPA2 Non-Enterprise (i.e. home) wireless is fine (from this).
And, of course, keep in mind it still takes 24 hours (right now, but that's sure to be sped up) to actually crack the DES encryption key with this exploit.  Since it's 24 hours and not 24 ms, that means an attacker will more than just casually find you and exploit you.  Your network will have to be a target first, at least to some degree.

Tuesday, May 1, 2012

Skype Leak

Skype has had its moments in security history over the past several years, like the allegations that governments of certain countries have backdoors (not substantiating or denying those here), but now it appears that if you know a Skype username, you can find out the IP address of the user.  Wow.

Saturday, April 21, 2012

Chances of Dying (InfoGraphic)

This is an interesting infographic that is floating around that depicts the statistical likelihood of dying from any given event.

It's a commonly known fact that societies tend to focus irrationally on certain threats over realistic ones, and this infographic just might help dispel some irrational fears that you hold.

For example, I was surprised to see that skydiving is less risky behavior than driving a car in traffic, which I do quite regularly.  Looks like it may even be roughly as dangerous as flying commercially (well, except you probably won't have to deal with the TSA when you get on that prop plane at a small rural airport prepping for your skydive).

Note how dangerous any mountaineering is in Nepal.  Ouch.  Not great odds.

Tuesday, April 17, 2012

White Lies Affect Your Behavior

This is an interesting article about recent studies in the psychology of honesty and lies.  Turns out that it's possible for a clever person to determine lies based on predictive human behavior under certain social obligations.  In other words, the presence of the lie is leaked information, divulged by other events-- a great read for those curious of information flow theory as it implies to security.

Monday, April 16, 2012

Free OWASP .NET Development E-Book

For your developer friends (or you), Troy Hunt made his book about the OWASP Top 10 web security flaws as implemented in .NET available as a free e-book PDF.  Plenty of good information in there to share with developers who need more clarification or a refresher in what it takes to build defensible web applications.

Friday, April 13, 2012

How To Send Digital Messages using HAM Radio

This is a bit of a stretch from the normal topics, but in a severe disaster scenario (think Hurricane Katrina or third world country), it may be desired to send real time digital text communication when there is no communication infrastructure in place any longer (i.e. telephone lines are down and the Internet "tubes" were all clogged up).

Here is a clever, low budget way to accomplish digital text communication over significant distances with very inexpensive components, namely a HAM radio, a netbook, an open source software application called FLDIGI, and a low tech way of connecting them together.

A clever improvement to this might be to encrypt the text data before its transmitted, which should be possible using a variety of tools, possibly even GnuPG (if the transmission medium is reliable enough to send the complete block of encrypted text without drops).

Wednesday, April 11, 2012

Measuring Wallets' Contents with Metal Detectors

Turns out it may be more than RFID protection you may need for your wallet. New Scientist reports how some academics at University of Washington - Seattle can exploit some of the metallic features of dollar bills to count the money in your wallet. An excerpt:
They found an ordinary handheld metal detector was able to pick up a dollar bill from 3 centimetres away, and placing the notes behind plastic, cardboard and cloth did little to block the signal. Adding further bills in $5 increments increased the strength of the signal, making it is possible to count the number of bills, though converting this into an actual dollar value would be difficult as notes of different denominations contain the same amount of magnetic ink.
Using larger metal detectors such as those found in airports should also increase the range of sensing, though detecting banknotes in such situations would be trickier as many other sources could interfere with the signal.

Saturday, April 7, 2012

Visa's New Data Center

We just covered the NSA's new data center, so it seems appropriate to mention Visa's new data center, complete with a moat!

Notice how castle features are still king for physically securing our data in the information age.

An excerpt:
The 8-acre facility looks like any other industrial park in a sleepy suburb. But the serene setting masks hundreds of cameras and a crack team of former military personnel. Hydraulic bollards beneath the road leading to the OCE can be quickly raised to stop an intruding car going 50 mph. Any speed faster, and the car can't navigate a hairpin turn, sending it into a drainage pond that functions as a modern-day moat.

The data center resembles a fortress, with dogged attention to detail. It can withstand earthquakes and hurricane-force winds of up to 170 mph. A 1.5-million-gallon storage tank cools the system. Diesel generators onsite have enough power, in the event of an outage, to keep the center running for nine days. They generate enough electricity for 25,000 households.

Once you get clearance from a guard station, get an OK from a roving security guy in a golf cart, and surrender a photo and fingerprint inside, the adventure begins.
Here is the exact location of the data center.  So much for trying to hide from Google Maps!

View Larger Map

Saturday, March 31, 2012

Stanford University Online Cryptography Course

Stanford University has a free online Cryptography Course. Looks very interesting for someone who wants to peel back the layers of the onion, but isn't scared off by the math. (Many applied cryptographers aren't necessarily experts in the theoretical mathematical aspects and vice versa.)

Professor Dan Boneh gives an introduction to the course:

Thursday, March 29, 2012

Using VPNs to Bypass Content Restrictions

Some content providers, like Hulu, have restrictions on certain content to make it only available in specific countries. They implement these policy goals in the form of restricting access to foreign-looking IP addresses.

If you are behind a foreign IP address and wish to view the content anyway, the current solution is to just use a VPN service to appear local.

Thursday, March 22, 2012

In Memory: Bill Zeller

Having just caught up on the positive achievements of Alex Halderman, we have discovered that another promising young mind has been lost forever.

Bill Zeller was also a member of Ed Felten's Freedom to Tinker crew and a PhD student at Princeton. Bill also is known for creating MyTunes, which was one of the first implementations to prove Digital Rights Management (DRM) is really the emperor without clothes.

You can read Bill's tragic story here, or his own words here. Even by those who did not directly know him, he will be missed.

Wednesday, March 21, 2012

Alex Halderman on Internet Voting

Computer Science Professor J. Alex Halderman is an upcoming academic star that we at Securology have been watching for awhile now, since some of the earliest days of all the great work put on at Princeton by Ed Felten and his Freedom to Tinker group (an excellent blog). Halderman, having completed his PhD (Bell Labs UNIX and C programming language creator Brian Kernighan was on his PhD committee!), has moved on to the University of Michigan as a member of the faculty and is continuing his excellent work at the intersection of technology and public policy, which always means security and privacy issues are in the spotlight.
Here is an excellent interview with Halderman (presumably shot at the 2012 RSA Conference) on how he and his students (legally) hacked the mock trial of Internet Voting put on by Washington D.C., and why Internet Voting should not be employed for a very long time.

In summary, there are two main reasons why Internet Voting is a horrible idea:
  1. Getting the software perfectly correct is, for all intents and purposes, impossible.
  2. Authenticating a voter eliminates the ability to anonymize the voter's vote (major privacy flaw).

Sunday, March 4, 2012

Thursday, March 1, 2012

Brute Forcing Credit Card Numbers

PCI Regulations allow merchants to store the first 6 digits plus the last 4 digits of a customer's credit card number. Ever wonder just how secure that is?

Well, without knowing anything else, if a credit card is stored as 1234-56xx-xxxx-1234, the possible missing middle digits range from 00-0000 to 99-9999, roughly one million (1,000,000) possible combinations. That seems very tough to guess (without being detected).

However, credit card numbers all implement Luhn's Algorithm, which is a special mathematical formula that uses the last digit in the number as a check digit. Not all of the 1,000,000 middle combinations will pass Luhn's check. Turns out (since modulus 10 math is involved), the quantity of missing middle number combinations is at most 100,000 possibilities, not a million. Luhn's reduces the complexity by an order of magnitude.

So, what if an attacker can get just one more digit somehow? Well, it's only 10^4 combinations then: 10,000 possibilities. What if they can get two more digits? The math follows this formula: 10 ^ (n-1). Here's the table:

6 digits
10 ^5 = 100,000
5 digits
10^4 = 10,000
4 digits
10^3 = 1,000
3 digits
10^2 = 100
2 digits
10^1 = 10
1 digit*
10^0 = 1

* It makes sense, if you're missing a single digit, Luhn's will help you recover it. That is the purpose of that algorithm originally.

Now, as far as practical applications for abusing the knowledge of Luhn's Algorithm on a PCI acceptably-formatted credit card number are concerned ... 100,000 attempted transactions to brute force a card number by a single merchant will certainly be detected and the merchant's ability to process any transaction will be in jeopardy. So, an attacker with access to a merchant account is probably not a valid threat to model.

For an attacker to attempt to make purchases at varying merchants with this brute force scheme and everything but the middle 6 digits, the attacker will also have to have the billing address and potentially the CVV code. That makes the problem significantly harder. But as the attacker can discover missing digits from the middle six, the problem becomes easier. If the victim is well chosen, and the attacker can do something like shoulder surf at a point of sale machine to visually see and remember a digit or two or three, then the problem gets noticeably easier. If the attacker can do that, the attacker can probably also guess the billing address and name. There's still that pesky CVV code, though (that's another 3 digits which compounds things).

Realistically, though, for an attacker to get that much information on a victim, the victim would probably have to be oblivious or have an extremely large line of credit to make it worthwhile.

For the rest of us, we're fairly safe with the PCI rules of first 6 plus last 4 digits being public knowledge.

Check this out for yourself. Here's the source code for a very simple C# console application that will take whatever first 6 plus last 4 digits you provide it, and churn out all of the possible middle combinations. Here is the inspiration for the C# Luhn's implementation. [Sorry about the code formatting.]

using System;
using System.Linq;

namespace Luhn
public class Luhn
private static int _middle = -1;
private static int _counter;
private static int _places;

public static void Main(string[] args)
if (!args.Any())

var cc = args[0].Replace("-", "").Replace(" ", "").Replace("x", "X");

if (cc.Length != 16)
Console.WriteLine("input is not correct length.");

_places = cc.Length - cc.Replace("X", "").Length;
var limit = Math.Pow(10, _places);

Console.WriteLine("Places: {0}", _places);
Console.WriteLine("Limit: {0}", limit);

while (_middle < limit)
var s = FindNext(cc);
if (!PassesLuhnCheck(s)) continue;
Console.WriteLine("Valid: {0}", s);

Console.WriteLine("\r\nFound {0} potential matches for {1}", _counter, args[0]);

private static void PrintUsage()
Console.Write("Usage: luhn.exe [credit card number]\r\n"
+ " in format like 1234-56xx-xxxx-1234\r\n"
+ " or like 1234-5678-xxxx-1234, etc.\r\n\r\n");

private static string FindNext(string number)
var middle = _middle.ToString();
while (middle.Length < _places)
middle = "0" + middle;
return (number.Replace(GetPlaceHolder(), middle));

private static string GetPlaceHolder()
var s = "";
for (var i = 0; i < _places; i++)
s += "X";
return s;

private static bool PassesLuhnCheck(string number)
var deltas = new[] { 0, 1, 2, 3, 4, -4, -3, -2, -1, 0 };
var checksum = 0;
var chars = number.ToCharArray();
for (var i = chars.Length - 1; i > -1; i--)
var j = chars[i] - 48;
checksum += j;
if (((i - chars.Length) % 2) == 0)
checksum += deltas[j];

return ((checksum % 10) == 0);

Wednesday, February 29, 2012

Traveling Light in a Time of Digital Thievery

This sounds exciting, like intrigue for spy fiction:
When Kenneth G. Lieberthal, a China expert at the Brookings Institution, travels to that country, he follows a routine that seems straight from a spy film.
He leaves his cellphone and laptop at home and instead brings “loaner” devices, which he erases before he leaves the United States and wipes clean the minute he returns. In China, he disables Bluetooth and Wi-Fi, never lets his phone out of his sight and, in meetings, not only turns off his phone but also removes the battery, for fear his microphone could be turned on remotely. He connects to the Internet only through an encrypted, password-protected channel, and copies and pastes his password from a USB thumb drive. He never types in a password directly, because, he said, “the Chinese are very good at installing key-logging software on your laptop.”
Never types his password in directly? News for you: if are concerned about only key stroke logging, you forget what other avenues of approach a threat can take if it's kernel resident. On-screen keyboards and even one time password tokens (e.g. RSA SecurID tokens) can and have been defeated as well. If this is your level of threat, these countermeasures aren't good enough. This should not be the extent of the threat to consider:
Both China and Russia prohibit travelers from entering the country with encrypted devices unless they have government permission.
Here's better advice:
Now, United States companies, government agencies and organizations are doing the same by imposing do-not-carry rules. Representative Mike Rogers, the Michigan Republican who is chairman of the House Intelligence Committee, said its members could bring only “clean” devices to China and were forbidden from connecting to the government’s network while abroad. As for himself, he said he traveled “electronically naked.”
and probably the best advice:
McAfee, the security company, said that if any employee’s device was inspected at the Chinese border, it could never be plugged into McAfee’s network again. Ever. “We just wouldn’t take the risk,” said Simon Hunt, a vice president.
The cost of doing business in places like that is the cost of "burn devices". The hardware, data, and software on them, should all be thrown away upon exit. Don't risk powering it back on. Like a disposable camera. Send your data in before you leave in-country, and let go of any and all emotional attachment to the hardware.

If China & Russia can do this, so can any other country or, perhaps even a commercial organization, of any substantial size (yes, even the United States can and will snoop on your devices).

DIY Drones

Do It Yourself Surveillance Drone Aircraft. Why? Because you still can.

Adjust your one-liner: "if guns drones are outlawed, then only outlaws will have guns drones".

An excerpt explains why:
It is extremely easy to build a drone now that can do not just surveillance but can carry rather large payloads. If you want to see how large some of these planes get, check out this video of a model Airbus A380. I don’t have to spell out the implications of this. I want to have my drone before the government makes them illegal. The US has been fighting such low-tech enemies lately that we haven’t thought through the nature of a world in which lots of people have sophisticated drones, not just other countries but private individuals. One somewhat worrying thing is that virtually all of this equipment comes from China or Taiwan.

Here's a flight video:

Thursday, February 23, 2012

John Nash Crypto Letters

John Nash (inspiration for A Beautiful Mind) wrote letters to the US Government in the 1950s which have recently been deLinkclassified and releasedLink to the public. Now you can read for yourself how John Nash was essentially 20 years ahead of the world around him in his plans for a cryptographic system.

The questions to ask yourself are: Did the US Government sit on this devised plan? If so, why? If not, how long were they keeping it to themselves before moving on to something better?

One thing can certainly be learned from history: powerful governments and organizations have kept tight lips on the cryptography they use, and stay far ahead of the power curve. Simon Singh covers the topic well in his book: The Code Book. (If this topic is even partially interesting to you, then you should at least read that book, if not buy a copy.) At each step along the way in recorded history, there have been parties wishing to keep their communications confidential, and significant disparities in the technology to do so. Charles Babbage's scheme for breaking the Vigenère Cipher comes to mind.

Tuesday, February 7, 2012

Verisign Hacked!

Verisign was breached according to an SEC report (Reuters), yet they report almost no details and act like it's no big deal!

An excerpt from Reuters (emphasis mine):

"Oh my God," said Stewart Baker, former assistant secretary of the Department of Homeland Security and before that the top lawyer at the National Security Agency. "That could allow people to imitate almost any company on the Net."
I knew instantly why Baker is a former Assistant Secretary to DHS: because he understands the gravity of a real security incident. Had he not understood, he would probably still be employed at DHS, along with all of the other laughing stocks and poster children for security theater.

Back on topic: Verisign is probably the single largest peddler of SSL certificates and their Certificate Authorities (CAs) are probably used by more browsers and other applications than any other. Talk about all your eggs in one basket! Not to mention their impact on the control of DNS.

In a past life as a customer of Verisign's certificates, I did not like dealing with them. They were arrogant, acted like they had no competitors, and charged exorbitant prices for their certs. That stated, the fact that mum's the word on what could possibly be the single largest breach in internet history is much cause for concern. If their private keys for any of their CA certs, including their intermediary certs, are breached, then anybody could impersonate any site they wish on the web.

First it was RSA being tight lipped on their SecurID breach, and now it's Verisign on who knows what was breached.

In the authentication world, there really only are 2 methodologies: A) hierarchical, or B) web of trust. Public Key Infrastructure (i.e. Certificate Authorities) are hierarchical. Essentially, we all trust a self-appointed few to discern for us who is authentic and who is not. In the web of trust model, that discernment choice is distributed among all the participants. You may chose to trust a website is your bank, you may not. The most common implementation of web of trust is PGP (the protocol, not the PGP company, which is rife with their own history of issues.) The con to web of trust is that your Grandma (or maybe even you) won't know who to trust, so she'll have a hard time setting up her {computer, iPhone, whatever}. In the hierarchical model, you don't have to think, but sometimes not thinking is a bad thing.


What can be learned from this?

1) Even the largest internet security giants can fall, and when they fall they hit the ground hard. A large, recognizable brand may not necessarily improve security. Though these incidents do not conclusively prove this, there is reason to believe that these companies present themselves as a treasure trove to their adversaries. They simply house assets of far greater value than what may otherwise be understood. Aligning your business with these high valued assets might be attracting unnecessary attention from web thieves to your business.

2) It is probably time to revisit the web of trust model.

Wednesday, February 1, 2012


This is a very premature response to what I believe is the single best solution to dangers like SOPA, PIPA, and ACTA: DNSCrypt.

To be fair, I don't think DNSCrypt in and of itself would be a solution to draconian "take the free out of internet" laws; however, it's going to be a very necessary component to maximize liberty in the 21st century. It's amazing the web has lasted this long without end-to-end crypto for DNS.

As stated in the link above, DNSCrypt is no replacement for DNSSEC. In fact, the ideal solution would be to rebuild DNS from the ground up using more of a web-of-trust model and completely end-to-end confidential and authenticated channels everywhere, with the ability to determine which "authority" you subscribe to for DNS and with resources listing themselves with as many authorities as they wish to be associated, ending the centralized (yet distributed for availability) control of the web. There's probably no reason to put that much power in the hands of a single entity anyway, and as governments continue on the path they appear to be on, locking down the web, isolated technical solutions will essentially create black markets for essential services like DNS.

For maximum persistence, an ideally liberated DNS solution would also need to float through filters, learning what it can from protocols designed to do so, like bittorrent, IRC, and basically any "cloud service" an enterprise IT Security team would want to block (those online drive storage services always seem to find a way through!).

And ultimately, wide-scale adoption is very necessary. It's excellent to see the inklings of that plan in DNSCrypt. Look at the choice to use ECC to preserve confidentiality. ECC requires low CPU overhead compared to other public key schemes, like RSA encryption, making it perfect for small devices like phones, wireless routers, and other embedded platforms to natively support DNSCrypt. Also important is for large scale providers like OpenDNS to support it. But like so many great technical solutions to problems, market penetration has been the deciding factor what wins out and what doesn't.

Even if DNSCrypt isn't perfect, it's a step in the right direction.