Slashdot Mirror
DARPA Delving Into the Black Art of Super Secure Software Obfuscation
coondoggie writes Given enough computer power, desire, brains, and luck, the security of most systems can be broken. But there are cryptographic and algorithmic security techniques, ideas and concepts out there that add a level of algorithmic mystification that could be built into programs that would make them close to unbreakable. That's what the Defense Advanced Research Projects Agency (DARPA) wants for a new program called "Safeware." From DARPA: “The goal of the SafeWare research effort is to drive fundamental advances in the theory of program obfuscation and to develop highly efficient and widely applicable program obfuscation methods with mathematically proven security properties.”
The objective of "mathematically proven security properties" via program obfuscation is definitely not achievable. After all, it's a given security principle of "security through obfuscation" is unsupportable. If an adversary is capable of obtaining the executable of a program, they can also reverse engineer that same executable. It may take a lot of effort, but it is always achievable.
Great, I look forward to code like,
*c+++=c+++1;
I sense buzzwords. I can prove mathematically that 1+(-1)=(-1)+1. If youre not specific, "mathematically proven" is just a buzzword.
I'm looking forward to the day when my phone, with a i16 CPU containing 64 cores, has the same end-user performance as my 486.
I'm amazed that someone who supposedly knows what they are doing would even suggest this.
Program obfuscation is completely the wrong approach. It is just another mechanism that relies on security through obscurity, which has been proven time and again to be a short-term solution at best.
When something is actually secure, it's readability should be irrelevant.
Pro tip for DARPA: use perl, hand out the source. Same end result but probably a few reverser suicides along the way.
$
So now on top of abstraction layers and lazy code we can look forward to wasting cycles on advancing the cat and mouse game of a security. I know I'm going to sound like an old codger, but my daily computing tasks have not really changed substantially since the mid 90s (emails, web browsing, shell access, word processing, etc). Streaming video and modern web technologies are awesome; it's not like there haven't been any worthy advances, but addressing excess power consumption, e-waste, and other associated issues would be a more worthy research goal IMHO.
This is a very different usage of "obfuscation" from what people typically use in everyday programming. It's coming out of some recent work in cryptography. See for example:
Candidate Indistinguishability Obfuscation and Functional Encryption for all circuits
http://eprint.iacr.org/2013/451.pdf
What this line of work may allow you to do is have a cloud computer run some code on some data for you, without revealing anything to the computer about either the code or the data. Without breaking the crypto the cloud provider can't know which of the many indistinguishable possible programs you've actually run. The downside is that there is an absurd amount of overhead in doing this right now (think minutes of computation per clock cycle per transistor used in the original computation).
For a little more discussion see:
http://security.stackexchange.com/questions/50937/describe-an-example-of-indistinguishability-obfuscation-or-functional-encryption
But there are cryptographic and algorithmic security techniques, ideas and concepts out there that add a level of algorithmic mystification that could be built into programs that would make them close to unbreakable.
This will never be allowed to work. Even if practical the surveillance community won't allow something secure to exist, even for the government, because it would leak out eventually to the public and harm the children.
This feels like a blast from the past, specifically the Trusted Computer System Evaluation Criteria (TCSEC) aka the "Orange Book."
DoD 5200.28-STD - December 26, l985
4.1 CLASS (A1): VERIFIED DESIGN
Systems in class (A1) are functionally equivalent to those in class (B3) in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. Independent of the particular specification language or verification system used, there are five important criteria for class (A1) design verification:
4.2 BEYOND CLASS (A1)
Most of the security enhancements envisioned for systems that will provide features and assurance in addition to that already provided by class (Al) systems are beyond current technology. The discussion below is intended to guide future work and is derived from research and development activities already underway in both the public and private sectors. As more and better analysis techniques are developed, the requirements for these systems will become more explicit. In the future, use of formal verification will be extended to the source level and covert timing channels will be more fully addressed. At this level the design environment will become important and testing will be aided by analysis of the formal top-level specification. Consideration will be given to the correctness of the tools used in TCB development (e.g., compilers, assemblers, loaders) and to the correct functioning of the hardware/firmware on which the TCB will run. Areas to be addressed by systems beyond class (A1) include:
DEF CON 20 - Tom Perrine - Creating an A1 Security Kernel in the 1980s
DEF CON 20 Archive
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Use a MS product - obfuscation is guranteed...it will be so dizzying...even the program's own developers won't be able to decipher it! It will combine the "beauties" of Microsoft "Help", Microsoft C/C#, .NET and throw in a little bit of Microsoft Bob for good measure!
But how do you scan code for back doors, trojans, viruses, malware, bots etc.?
Software obfuscation confronts exactly the same core problem as DRM: The goal is to both provide information, in usable form, and not provide the same information, to the same recipient, at the same time. That's impossible. So in both cases all you can do is to try to raise the bar, make it harder to extract the convenient form of the information, but "mathematically proven security properties" must be forever out of reach.
Unless maybe they define "obfuscation" differently than I do.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I think what they are asking for is a virtual processor that executes encrypted instructions on a physical processor through homomorphic encryption. Existing techniques for this are insanely slow. They want some new math to make it faster, so that it's practical.
Unless maybe they define "obfuscation" differently than I do.
BINGO! Ladies and gentlemen, we have a winner!
No, not all security is obscurity. If your list of things that need to be kept secret includes your security implementation, and especially your algorithm, then you have flawed security. Multi-level security increases the number of things you need to have and/or know in order to compromise the system. With e.g. ROT-13 or another shift cipher, once you know that they are using that cipher, there is no other knowledge that you need in order to break it. On the other hand, if you have an arbitrary number of keys and the knowledge that your opponent is using e.g. SSL, you don't have any greater ability to compromise other users.
Security through obscurity may be an overused phrase, but it does have a specific meaning; it only really makes sense in the context of security systems. You may use words however you wish, but to me that's not glory.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
DARPA is trying to improve virus/malware? Could have been the title.
This program contains graphic material,
including Microsoft Bob.
Viewer discretion is advised.
According to Eric Holder, information security == material support for pedophiles. I expect the DOJ to promptly due DARPA out of existence!
...interpret the obfuscated source code, then why wouldn't a human be able to?
Yes! It is a Macintosh from 1994 running Mac OS 8.3.
Ha ha
Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with.
Kevin Horton (kevtris in #nesdev on EFnet) writes circuits in Verilog for a living.
You could argue it took nearly 20 years to crack. Not bad for security through obscurity.
But not nearly as long as what the industry wants, which is 95 years after first publication.
So yet another fancy pants security scheme that probably won't really fundamentally change anything?
At this point, wouldn't it have been cheaper to bite the bullet and go back to capability model computing even though it requires recoding of pretty much all our software? (OS400 used to do that sort of thing and the AS400 seem to have been pretty solid security wise; also it is apparently mathematically provable that capability model based software can be made secure)
On the plus side doing that should guarantee a revenue stream for the software industry that is not petty renting of software, if they can get back to some good old upgrade cycles due to the necessary overhaul.
As a bonus the recent announcement of a capability model enhanced 64-bit processor with modified FreeBSD seems to imply that the whole ordeal might not even be too bad.
... a different language. Take Ancient Egyptian... without a Rosetta Stone there would be no means to translate it. The whole structure of the language was inscrutable without some sort of introduction to it.
Your program and system ideally should run on custom hardware. Not known computer hardware that must conform to known standards. The system will not be as fast or cheap. But it will be so different that it will be difficult to understand. And what a programmers cannot understand they will not be able to hack.
Have a unique hardware platform. Reinvent the computer but do it differently enough that no existing technology is similar. And then come up with your own operating system that is likewise just different.
Building, maintaining, and operating such systems might be a pain... but they'll be very secure.
The systems that translate between these systems and the rest of the internet should be top secret. Lose one or get it compromised and you have to start all over again.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
This really is BS. Sure, you can obfuscate complex function, e.g. mathematical functions, to the point that reading the code becomes pretty hard. (That includes most crypto, but note that non-standard crypto has a tendency to be insecure and standard crypto can be recognized.) But even there, an attacker can simply try out the functionality and recognize what it does for the cases that matter. For simple functionality (and most functionality is simple, e.g. data access or access control), this does not work at all. Obfuscate all you like on these, it is easy to find what they do.
Really, all security-related code that can be written, can be analyzed as it has to interact with its environment and that gives away what it does. This is just another "magic" technique that will continue to fail delivering, while unscrupulous researchers will be getting grant after grant based on false promises. I find that pretty reprehensible.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
ouch that hurts
is the lamest title i've ever heard..
Black Box Hacker Challenge. Or variations on the name. It's what I'm calling it.
OK, before you start with "HONEYPOT!", no it isn't, and this isn't a new idea either. It's been done. Many times. By lots of companies. Including Google - and the NSA, and all to test security on various bits of software outside of lab conditions. In case you're new here, a BBHC is a standalone or more commonly an integrated part of, a hacker convention where you take a blackbox (literally, hence the name of the game) loaded with code or some other prize and challenge the participants to break into it - often with a hard time limit. If the challenge beats the players, it can be reasonably assumed that that bit of code is reasonably secure. If it's broken, the usual response is to bow out gracefully after handing over the prize and figure out where you went wrong for the next time round. Or maybe the prize is a salaried position (mmm, work in the public cybersecurity sector, any insiders care to share whether they think there's job security in that?)
Out of interest, has the Google Pwnium 4 Chromebook challenge been beaten yet? I can't find anything on it. Maybe I'm looking on teh wrong interwebz.
Some great examples of conventions where BB challenges occur with regularity are Blackbox, HackInTheBox, PPC, DefCon, ICS, CanSecWest.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
This seems like something only useful for malware. After all the only reason you don't want the person to know what code they run is to do something they don't want you to do. And that's essentially the definition of malware.
Actually, there's some weird math going on out there.
"Obfuscation" in this context refers to a specific mathematical adventure. It has a neat property that if I implement an algorithm two different ways, and run one of them through an "obfuscator", it's provably impossible to figure out which one you started with, given the obfuscated program.
That's fine, and interesting. But here's where it gets cool: If I use one interesting secret to implement the algorithm one way, and a *different*, interesting secret to implement it the other... where is the secret? If it's provably impossible to identify the original algorithm given the obfuscated code, then reverse engineering the obfuscated code must contain neither secret. Or Both. Or ... something else?
Once you add all your caveat you have a pretty piece of hardware which gives you number you cannot see the function is for, while good for hardware, most software in the real world do not work like that. Once you start unrolling the instructions, consider input and output, then sooner or later depending on how much effort you want to have, you won't be able to hide your program inside working. The simple fact is that contrary to your hardware argument, the software has to be executed by the CPU. Frankly you can hide far more stuff from the common mortal with hardware than you can with software.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
If they succeed to create such tool, they will soon want tool that can unravel what the first tool did, just because China/Russia...
Isn't TOR the textbook example of that?
It's obvious they want to study this not to become more secure, but to understand how to attack someone using this approach more effectively. If they build one from the ground up they will see incrementally how to attack at each point. It's likely this is reactionary.
C'mon people.