10 Replies - 2751 Views - Last Post: 07 July 2012 - 02:05 PM

#1 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Authenticating data generated by official build of an open source app

Posted 05 July 2012 - 09:42 PM

I've posted this question last year to crypto.stackexchange.com, and the general consensus is that this problem is unsolvable. One cannot hide anything in a program running in a hostile environment under full control of an attacker. About all I can do is to try to slowdown a determined hacker or make actually competing in the game more interesting than trying to hack the program. I'm reposting here almost a year later in the hopes of generating discussion and perhaps have people put out ideas on how to harden the system.

One of the suggestions was to use TPM hardware and use remote attestation. I have yet to figure out how to submit a running C# program for remote attestation, much less prevent a malicious program from submitting a good running program and taking the results as its own.


Question: How do I assure myself that the results data submitted to me was generated by my official build of an open source program?

I'm developing an open source program. The program essentially collects data, performs some calculations, and sends back the data and results to me. The program is for all intents and purposes offline. More often than not, I'll get the results data back via a single HTTP post of XML data if I'm lucky, or more likely an emailed XML file, or a USB key with the XML for pure SneakerNet mode.

I will be releasing official builds of the program with the appropriate Authenticode signatures. (My target platform is Windows.) The Authenticode signing will prevent tampering of the program. Presumably, the program will be digitally signing the results data to prevent tampering of the data as well as establish the chain of evidence that the data was generated by this particular build. But how do I go from these "hand-waving" concept to actual implementation?

Since the program is open source, anybody else can also build the program, examine how it works, and potentially modify the program to perform some "cheating" or the results data that sent, as well as bypass any self-integrity checks I may embed in the code.

Here is what I've thought through so far:

Obviously, I'll be the only one holding on to the code signing keys. First layer of defense would be for the program to do a self-check for a valid Authenticode signature on all binaries. As as next layer, assuming it's doable, is verify that all binaries were signed using the same signing keys. I don't want to hardcode any attribute of the signing keys just in case somebody else wants to build their own official builds and verify that they are getting results from their official builds.

Although, the program integrity seems to be good, since it's open source somebody can always edit the code and make a build that doesn't do any self-integrity checks. :-(

The next bit of the puzzle is putting some characteristics of the running program binaries into the results XML. This could be simply a hash of all the running binaries. My server that accepts all the data can check the hash for a known good value. A malicious build can't bypass putting in a hash if the results data to be considered valid by the server, but it can just go ahead and compute the hash of all the official binaries and put it in the results XML. Essentially a replay attack. :-(

The next bit of the puzzle is how to digitally sign the results XML. This is a biggie. To do XML digital signatures, I'll need both the public and private keys. How do I embed these two keys into the program? Obviously checking them into source control is a really bad idea. :-(

I can hold the keys private the same way I held the code signing keys private and only at build time insert the keys as resources into the program. But I'm essentially publishing those keys once I release an official build. Anybody who looks at the source will discover that the keys are held in the resources and can get the keys themselves. :-(

Is there a public key system where I can generate my own private/public key pairs using characteristics of the official binaries? But this still suffers from the issue as above where a malicious build can just pick up those same characteristics from the official build. :-(

Think of this problem as building an open source voting machine. The Commission of Elections would like to build its own machines and distribute these for the elections, but it wants the source open to the world so that there are no rumors of impropriety. The commission doesn't care if the local Rotary club also makes their own voting machine for their board, but that machine should not be used to submit votes for the US Senate.

Any help or guidance on where to look for possible approaches to solve this problem would be most helpful.

Is This A Good Question/Topic? 0
  • +

Replies To: Authenticating data generated by official build of an open source app

#2 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8897
  • View blog
  • Posts: 33,369
  • Joined: 12-June 08

Re: Authenticating data generated by official build of an open source app

Posted 05 July 2012 - 10:04 PM

You seem to be wanting two things - integrity and openness. Integrity requires *SOME* level of secrecy, right? You are not flopping out your keys and info in the wind, right? You might have to fork your program - one that has the security bit obscured the latter being the open source where the implementers have to do their own security.

Oh and something about cake and eating it too..
Was This Post Helpful? 0
  • +
  • -

#3 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Re: Authenticating data generated by official build of an open source app

Posted 05 July 2012 - 10:56 PM

LOL!

That was one of the side threads and discussions last year. If I hold back some source code (like the security checking code), can I still rightly call it open source? (Or phrased another way: Can Linus release Linux and hold back the file system code and still call it open source?)

What I recall was that holding back signing keys, visual assets, and other binaries that "brand" the build as long as there are placeholder files, no problem. Holding back key components and algorithms, not okay. e.g. People should be able to build a runnable product from the source.

I've always been taught that good cryptography is open and maintains integrity. The security and secrecy comes from the difficulty of undoing the computations done by the algorithm, not from withholding information about how the algorithm works. Of course, this has always been with the model where the computations are done in a "safe" environment, and not where the bad guy is sitting on the same machine and watching the key values going into the algorithm.
Was This Post Helpful? 0
  • +
  • -

#4 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8897
  • View blog
  • Posts: 33,369
  • Joined: 12-June 08

Re: Authenticating data generated by official build of an open source app

Posted 06 July 2012 - 07:13 AM

Sure - but as you said if this is open source the ne'er-do-wells can just bypass authentication so any particular scheme you have is out the window. Essentially it's not about the crypto being hard to crack it's about how you vet your data.

Though in theory - with each version release attach a public PGP key. Heck you can have a new one for each major release... if the data is coming in is *NOT* encrypted then don't accept it. If it is encrypted but not with the latest key... don't accept it.

This means with release of *YOUR* code.. you provide the PGP key with the app as a resource. When the app goes to "make my data file" it checks for that key. If there it encrypts it. If not then it shoots out plain text. A simple case right - where you keep your key in embedded as a resource or not. Now the open source doesn't have your key.

As long as your key is only in your compiled and released versions of the app then that ensures that someone is out there just running your code from github and tinkering with values in debug mode to send you the file.
Was This Post Helpful? 0
  • +
  • -

#5 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Re: Authenticating data generated by official build of an open source app

Posted 06 July 2012 - 10:17 AM

Thanks for the input. This kind of discussion is exactly why I started this thread.

Unfortunately, Joe Cheater doesn't have to be sitting there with a debugger. He can simply add in his build of the code:
var goodAssembly = Assembly.Load("official.exe");
var signingKey = goodAssembly.GetManifestResourceStream("SigningKey");
doctoredXmldocument.SignXml(signingKey);



I can probably encrypt the key as an additional layer, and as another layer randomize the resource name. As yet another layer, I can have multiple keys and the key is chosen based partially on the hash of the data and the running assembly.

It's all just an arms race, though. I'm open to any ideas about how to extend the arms race or even do a major leap forward. Perhaps just make it complicated enough to not make it worth it.
Was This Post Helpful? 0
  • +
  • -

#6 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8897
  • View blog
  • Posts: 33,369
  • Joined: 12-June 08

Re: Authenticating data generated by official build of an open source app

Posted 06 July 2012 - 11:24 AM

I still think this is be the best answer - you hang on to the key and the open source doesn't. Throw in an obfuscator to scramble the code (the code you distribute with the key - and not have this with the open source bit) then there you go.

Of course there seems to be some sort of mixing burdens on what you want to accomplish. Encryption gets you only so far with confidentiality - but you are looking to roll authenticity in there. You'll need away to ID your app - that you compiled - without confusing the open source.

So there are options with that - digital signature - encrypt - outer signature... or ESE.

http://world.std.com...n_encrypt7.html


The other way would be to make some sort of three-way handshake of validation codes..
use sends the file
you send back a code (based off the file) and something like the build number or what not.
the user enters the code and sends back the a new response code.
if that checks out on your end then there you go..
in the mean time the data is holed up until this is done.
Was This Post Helpful? 0
  • +
  • -

#7 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Re: Authenticating data generated by official build of an open source app

Posted 06 July 2012 - 02:36 PM

Actually, I don't need confidentiality. The data is open to everybody to see, this is why I'm using XML signatures. The XML data can be easily seen and parsed, but to truly check of the authenticity of the data, the signature must be checked.

No doubt about it, the key needs to be on the client for it to be able to sign the XML. As you mentioned before, only the official builds will have the signing key. Part of the issues I'm facing is how to protect the signing key and/or the code so that the key isn't extracted so that Bad.exe can use the key, and that Bad.exe can't do some kind of spoofing to make Good.exe sign bad data for it.

Obfuscation will definitely help make it harder, but with open source, the attacker knows exactly how the code works so obfuscation is moot.
Was This Post Helpful? 0
  • +
  • -

#8 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8897
  • View blog
  • Posts: 33,369
  • Joined: 12-June 08

Re: Authenticating data generated by official build of an open source app

Posted 06 July 2012 - 02:44 PM

Ugh.. for Pete's sake - stop being so darn defeatist.

Check it - your average obfuscator can hide resources. Geeze. Less hand waving - more researching!
Was This Post Helpful? 0
  • +
  • -

#9 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Re: Authenticating data generated by official build of an open source app

Posted 07 July 2012 - 02:24 AM

Not being a defeatist. Just being a realist. :lol:

I know that obfuscators can hide resources. When I originally posted the question last year, I'd already done that research. Obfuscation can only do so much if the attacker knows how the code works.

Let me give a simplistic example: a winform app with a single textbox. The attacker's objective is to intercept the string entered by the user into the textbox. The attacker knows that there is only a single form, and that form has only one textbox. So all the obfuscation in the world is not going to do squat when the code eventually gets the hlahu property from the llmoua control and that the llmoua control was create as a child control of the oaimd12 form.

Going back to the key as a resource, if there is only one resource in the assembly, and the source code reveals that there is only one resource that is expected to be in the assembly, then the game is up very quickly. So I can put multiple resources where the other resources are decoys, but as previously mentioned, it's just a matter of watching the code pull one of the resources for use.

This is part of the reason I floated the idea of having multiple keys and the key choice depends partly on the data to be signed. The attacker will now have to not only keep track of multiple keys (with obfuscated names), but will also have to account for which key is chosen depending on the data to be signed. More difficult, but not insurmountable.

Security by obscurity can only go so far.

Maybe part of the reason why it may seem that I'm down on security by obscurity is that I've watched and listened to the hackers who managed to crack Skype's security. The Skype security system is incredibly complex with multiple integrity checks, false leads embedded in the code, self-modifying code, and other security measures, but these guys who didn't even have the source code managed to unravel it all, and draw graph showing the complexity of the system. The graph even partially zoomed made a the circuit map of a modern microprocessor look simple by comparison.
Was This Post Helpful? 0
  • +
  • -

#10 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8897
  • View blog
  • Posts: 33,369
  • Joined: 12-June 08

Re: Authenticating data generated by official build of an open source app

Posted 07 July 2012 - 11:26 AM

No - you are not being a realist. A realist would accept a certain number of inevitable collateral damage, but also realize that 100% security is not possible in the scenario you are setting up. You provide little limitations when you should be imposing more, and odd stringent limitations when you shouldn't be.

Okay - so you are comparing your app to skype? Sure - obscurity is fine and dandy but let's inject some critical objectivism into the discussion - is your app even worth their time?

It goes back to you wanting opposing things - you want it open source but also some sort of security and authenticity... You claim this app is going to be offline (mostly).. well that throws in a wrench of having it jump out to your controlled server for some sort of key registration. (As in before who ever uses your app for what ever they will use the app for - their app dials out to your server who dispenses a one time key good for X hours.. any data coming in from that party needs to have that one time key with it for part of the encryption and sending of data back to you.) You also keep throwing out this mythological "do-everything-hacker" that handwaves and destroys everything.

I have no idea what your app is doing or why people would have interest in cracking it, but the reality is an obfuscatory - that drops off the resources (encrypts and hides) from reflection - will do good enough. That will prevent what - 97% of the people who actually look into the app? The other three percent seem like an acceptable casualty rate.

So unless you are going to code a special chunk for your application (that is not part of the open source build) that has some sort of key encrypted in a ball (again - for your distro only) that houses other keys and signatures for validation (if it can't find the ball of keys and signatures it just shoots out plain text) - or have the app jump out to your server for some sort of controlled key - then a well repped obfuscator is your last line.

Certainly if you want to beard-stroke a theoretical construct then by all means go ahead... but I've been in these discussions at work and solutions presented themselves (or were just made clear to the hyperventilating parties) that the specific requirements to using the app (an internet connection, closed chunks of code, obfuscators, digital signatures, regimented user lists, one time keys, etc) made the application secure enough for real world use.

Take control of the theater your software operates in (when I say that I mean the one you plan on distributing not the open source one) then pathways open and close as needed. It's not unheard of that *YOUR* version of the application has specific set of rules and usage needs that are more strict than say the open source one. No one will blame you for that. You would be doing what you expect your open source consumers to do - take your own code and tweak it for your needs. There's no restriction barring you from doing that.
Was This Post Helpful? 1
  • +
  • -

#11 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3450
  • View blog
  • Posts: 10,649
  • Joined: 05-May 12

Re: Authenticating data generated by official build of an open source app

Posted 07 July 2012 - 02:05 PM

That's the best piece of advice, right there: figuring out when the layers of protection are good enough™, and figuring out what is an acceptable casualty rate.

My comparison to Skype was to point out that a determined enough hacker can get past security systems. You make a good point that it has to be worth their while. For the Skype hackers, they weren't hacking skype to get free calls. They were hacking for the sheer challenge that was present.

As for my app, I was considering the worst case attacker. I was doing this because some of the cheaters in my sport for which this app is supposed to collect data for have been known to go to some extremes to cheat.
Spoiler

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1