Friday Squid Blogging: William Gilly, Squid Researcher

Good article.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Posted on December 28, 2012 at 3:16 PM • 17 Comments

Comments

Petréa MitchellDecember 28, 2012 9:17 PM

There is an ongoing investigation of the FBI crime lab because shoddy practices may have resulted in wrongful convictions. And:

But about three dozen FBI agents trained 600 to 1,000 state and local examiners to apply the same standards that have proved problematic.

None of the local cases is included in the federal review. As a result, legal experts say, although the federal inquiry is laudable, the number of flawed cases at the state and local levels could be even higher, and those are going uncorrected.

When I looked at this article earlier this week, it had a sidebar with more information on the scientific basis (or lack thereof) for some popular forensic techniques. That seems to have vanished, though.

mike ackerDecember 29, 2012 6:20 AM

Fixing the Point of Sale Terminal (POST)

The POST will need to be re-designed to accept customer "Smart Cards"

The Customer Smart Card will need an on-board processor, -- with PGP

When the customer presents the card it DOES NOT send the customer's card number to the POST. Instead, the POST will submit an INVOICE to the customer's card. On customer approval the customer's card will encrypt the invoice together with authorization for payment to the PCI ( Payment Card Industry Card Service Center ) for processing and forward the cipher text to the POST

Neither the POST nor the merchant's computer can read the authorizing message because it is PGP encrypted for the PCI service. Therefore the merchant's POST must forward the authorizing message cipher text to the PCI service center.

On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer's account to the merchant's account.

The POST will then print the PAID invoice. The customer picks up the merchandise and the transaction is complete.

The merchant never knows who the customer was: the merchant never has ANY of the customer's PII data.

Cards are NOT updated. They are DISPOSABLE and are replaced at least once a year -- when the PGP signatures are set to expire. Note that PGP signatures can also be REVOKED if the card is lost.

mrUniverseDecember 29, 2012 10:35 AM

@mikeAcker
some aspects of that system look good, but I really question the use of PGP vs a more scalable PKI solution. While I'm sure you would be happier with such a decentralized/privacy-focused/anarchist-friendly system, it simply isn't scalable without inviting widespread theft/fraud, and 99% of businesses/consumers would rather have less privacy than deal with the level of complexity (and compromise) that your system would entail.

mike ackerDecember 29, 2012 10:44 AM

@mrU
PGP is a well respected product . i have worked with it since version 2.6 and i see no reason it would not be suitable for this purpose . one of the keys to fixing the security issue is reducing the attack surface by taking the merchant's computer as well as any pocket phones - out of the mix

there is no reason this cannot be set up as packaged technology such that it is just as easy to use as existing debit cards .

Petréa MitchellDecember 29, 2012 12:11 PM

NobodySpecial:

And then award the contracts based on who gets the best results for their customers = the police

What's the definition of "best" here?

MortDecember 29, 2012 5:35 PM

Maybe it has been mentioned before, but the recently announced BLAKE2 hash function is interesting; it tweaks BLAKE to be as fast as MD5, which solves the "no benefit over SHA-2" problem.

The main trade-offs seem to be a lower safety margin (less rounds), more control over the initial state, and a lot of knobs (parallelism, 32-bit vs 64-bit, tree-mode, etc...).
It could probably be useful for internal applications after it has gotten some love/scrutiny from other cryptographers.

FoxpupDecember 29, 2012 8:44 PM

@mike acker
Bitcoin already does almost exactly this (although a smart card system has not (yet) been developed for it), except transactions are only signed, not encrypted (nothing in Bitcoin is encrypted, contrary to popular belief). Privacy is protected by not having PII linked to the customer's public key; the only thing that is linked to the public key is the previous transaction(s) crediting the customer's account. To regain the privacy that is lost by linking previous transactions to public keys, a new key-pair can be generated for every transaction (one person can have as many keys as they want).

But ultimately, as with any security solution, the problem is not in developing the technology, but in convincing people to use it. Many people are unconvinced that Bitcoin solves any problem with existing payment technologies.

kashmarekDecember 30, 2012 7:09 AM

"NobodySpecial:

And then award the contracts based on who gets the best results for their customers = the police

What's the definition of "best" here?"

The definition of "best" is that an arrest was made and/or conviction secured. Breaking the law or actual guilt is unrelated.

paranoia destroys yaDecember 31, 2012 7:08 AM

Looking at the web logs, I've had several attempts lately to access oscommerce files on my private web site. The hitch is that I don't have a store.
To mess with them, I added folders with the names being looked for and redirected them to a web page saying that I have a hacker mentality like them.
Would creating false paths for the crackers to follow waste their time instead of wasting mine?

Nick PJanuary 3, 2013 1:03 PM

@ Paul Suhler and others

It's an interesting read. It looks like one source of the article was stumped by the halting problem and inspired into this stuff. Others worked around it. I'm sure we'll get some interesting stuff out of the research. However, to actually secure things, we've learned over the decades what it takes. Most of what's in an Orange Book B2 (EAL5-equivalent) system's assurance requirements is better than modern systems' security. We had plenty of EAL5-7 systems production ready (and used) in 90's.

The old efforts taught us about development and economics. DJB's qmail put some of these principles to work and has been used with few to no security issues for years. XTS-400's are still around with more apps than before doing MLS security. Aonix (Java) and Adacore (Ada/SPARKS) offer development platforms for embedded software that dodge many issues caused by C/C++. JX is a whole OS stack running on a JVM with security elements comparable to EAL5-6. Cutting edge developments aim to produce processors that enforce security at the word level.

Some random musings about high assurance and UAV security follow.

Controlling subversion and ensuring requirements are met.
http://www.schneier.com/blog/archives/2011/07/...

Here's a modern example of an old concept that helps a lot. The concept was splitting the system into trusted and untrusted components, reducing the amount of trusted code, and making the underlying TCB small/strong. Orange Book did that with security kernels. MILS is more typical today. Microkernels and separate processors are other solutions. This concept can help solve MANY problems.

One problem that UAV's face is interfacing operators to control. Ideally, we can have fancy GUI apps with OpenGL on our favorite OS. Ideally, we have full-featured Linux/BSD type networking options and plenty of link transmission types on UAV. Ideally, external input that's malicious can't bust through the system on either end in a way that affects control. Reality: modern setups are far from ideal. Another reality: getting pretty close to ideal is actually easy using the concept I outlined above.

Pretend there's one UAV operator console, a single UAV, and one radio communication link just for conceptual simplicity. First, we put a dedicated gateway between the operator console and possibly malicious network. This gateway runs high assurance software (e.g. Aesec's GEMSOS or a SKPP kernel). It receives outgoing commands, performs sanity checks on them per a policy, and sends them through a VPN tunnel. Tunnel establishment is done in a very robust way. The gateway also receives information from UAV, performing minimal checks, and sends it to operator console. Separate Ethernet/Networking stacks are used for each side and data is copied between them by TCB.

OperatorConsole->Gateway->UntrustedNetwork->Gateway->UAVcomputer

Within OpGateway: UserIPPackets->UntrustedRedNetworkingStack->GuardProcess->TrustedCryptoCore->UntrustedBlackNetworkingStack->UntrustedBlackNetwork
(Incoming works similarly in reverse. Independent modules for functions like setting up VPN connections, auditing, etc. UAV's gateway is similar, but a more embedded design.)

NSA and high assurance system developers can do a design like this because it's the kind they've been doing for decades. Just use secure kernel for TCB, split everything else into untrusted/semi-trusted partitions, and use assured pipelines to move data. I'd isolate GPS into it's own partition. I'd also include a process that, much like Clive's ideas, occasionally peeks into the partitions to ensure nothing is amiss. All data transfered from an untrusted partition to a trusted one must use a simple data format that's easy to parse and inspect (not XML!).

So, let's look at the issues. A component fails? Damage is isolated into a partition. Monitor notices, optionally logs some info on it, restarts the partition, and system continues as usual. What of network attackers? Well, traffic goes over a VPN whose endpoints have simple networking subsystems that are also isolated. What about a UAV issue? The gateway TCB can host monitoring software that detects issues, performs auto fixes or simply alerts operators.

What about malware on operator machine? Well, that usually indicates organization security issues ;) but the architecture helps: commands are sanity checked; no malware will be uploaded; rogue comms can be caught by monitoring; a compromised PC can be shutoff and doens't even have direct connection ability to UAV. Recovery? Hypervisors or coprocessors might be used on either node to allow the gateway/monitor to push updates. So, can quickly patch console or hotfix UAV control in mid-operation. Also, makes managing typical updates easier.

(Anyone thinking about what this REALLY means for the console might see why I prefer a non-Windows/x86 solution to the problem. Ideally, we'd have a SOC with simpler-than-x86 processor, few errata, MMU, IOMMU, onboard crypto, a ROM with high assurance base secure loader, flash for storing signed firmware/system images, a dedicated IO link to gateway, and everything built on top of THAT.)

So, you may be thinking: great, all we need is to spend a few years building this gateway thing and port some UAV operator software to a SOC. No, it gets better: them doing this crap for decades means there's many actual commercial products, prototypes, partial designs and design guidance in Lessons Learned-type papers. Here's a few options below.

Aesec just presented a high assurance guard design with isolation, assured pipelines, and GEMSOS security kernel at MILCOM 2012. The XTS-400's STOP OS was originally B3/EAL6. It's been used in guards for a long time and has Linux compatibility layer. Nizza and Perseus security architectures were used to build complicated applications whose security-critical parts were isolated on a microkernel. SKPP-like platforms are available for this too: INTEGRITY-178B (certified EAL6+), LynxSecure, VxWorks MILS (in eval for EAL6+), PikeOS (partly verified through Verisoft), OKL4/Verified (EA7+ design/implementation, not certified). The old KeyKOS, LOCK, and related projects could do things like this. Boeing SNS server (A1/EAL7 design) is still around for defense use and Boeing proposed a secure networking architecture around it.

So, it's not that they don't have the technology. They just keep reinventing the wheel and not using what they already have. Even my design eliminates many problems they might have. Simply rewriting the operator console software in type safe language running on a Linux VM (or write-preventing kernel) with app whitelisting and USB ports disabled would help plenty. ;)

Honestly, I think these companies just aren't trying to make secure platforms. The intense competition in UAV IT space means they are more focused on features and time to market. Their pace or profit motive keeps them from embedded security into each step of the design. It's the same old problem that killed the A1/EAL7 VAX VMM Security Kernel project. The only time things were different was when NSA/DOD mandated high assurance products for critical stuff, promised to buy only those and actually bought/used them. The moment they started deploying Windows NT and low assurance security products in mass was when everyone stopped building secure stuff (per Bell).

All the security research in the world won't change economics and IT sociology. Defending networks and systems isn't as much of a technical problem as people think. It's usually just a management or customer choice. They usually choose against high security.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..