1

I'm currently trying to develop a client-server structure, with the client being in .NET and the server being a PHP based SOAP server.

Now, I'm trying to implement an asymmetric key system using Rijndael 256 and a bit of fiddling about. I understand the basic concept of a public/private key pair (as per this page & Wikipedia), however I cannot get my head around it being secure in any client-side environment.

In short, the software will be running on the client machine, so the user will have the ability to tamper with the software. Most of the client's functionality revolves around responses received from the server in order to display reports & details. Along with that the client software will occasionally await a command from the server, where the server will tell the client to show a pop-up or execute a client-program shutdown (to do with licensing). I realise the server may crash or hang, or the client gets disconnected. Most of this has all been thought over and handled in code. But what I'm worried about is someone tampering with the client so that it completely ignores the server's commands.

The customer will have access to a wide variety of 'toys' such as IDA, ILDASM, de4dot and various other debuggers and/or decompilers and Im fairly certain an experienced cracker will be able to figure out the public/private key combination within a short period of time. I know .NET code on its own is very insecure, but I'm not sure what to do against that other then using tools such as .NET Reactor & Dotfuscator etc.

My question: what sort of practices, code, ideas or anything can I put to use in order to either severely delay said cracker, or rather, how do I protect the private key at all costs.

Any hints, tips, suggestions or samples very appreciated!

  • 1
    "... and a bit of fiddling about." uh oh... are you sure you understand, what asymmetric keys are used for? They're not used to encrypt your software. They're used for secure communication between two parties (usually client/server). Basically, the client encrypts his authentication info (login/password) and his public key with the public key of the server and sends it. The server decrypts it with his private key, authorizes and encrypts a symmetric key with the clients public key and sends that back. The client decrypts the symmetric key with his private key and the rest works with that skey. – Corak Jun 11 '13 at 11:56
  • And those key pairs can be created at runtime. They don't need to be stored anywhere. How does the client know what the servers current public key is? He simply asks the server. it's a *public* key after all. The server could even create a new key pair on the fly for each login attempt. – Corak Jun 11 '13 at 12:11
  • Have you read up on hashing? And have you thought about using a _symmetric_ key instead? – Sam Jun 11 '13 at 12:12
  • I do understand where asymmetric keys are used for. My apologies for not putting down a clear question. My issue is not communication, I worked that out and it's just fine. It's more about how to protect that private key once the software generated, keeping in mind users can fiddle about as much as they want regardless of what anti-debug techniques I seem to apply. How do I securely store the private key inside (or perhaps outside) my code/client software? –  Jun 11 '13 at 12:14
  • 1
    Why do you want to "protect" the private key? As I said, you don't need to store it anywhere. Not even in code. Just create a new pair at runtime (on the fly) when you need it. – Corak Jun 11 '13 at 12:17
  • "asymmetric key system using Rijndael 256" really? Are you aware that Rijndael is a symmetric key encryption? – Igor Skochinsky Jun 11 '13 at 12:47

1 Answers1

1

As @Corak stated, public/private key pairs usually work by keeping the private key private. On the client side, you can generate a new public/private key pair every time you connect. The easiest data to hide is the data that isn't saved in the first place.

The other part of your question is "how to stop a cracker!" That's not possible because the end-user has full control of the machine. You can play tricks to try to obfuscate your private key in memory, keep it out of the swap file, etc., etc., but any cracker with suitable tools and desire to crack your program will do it.

UNLESS!

You can partner with leading hardware vendors. Have them install a super-secure chip on all their hardware, and this chip will be under your control and not the user's control. When activated, this chip will monitor all I/O and memory and only allow what you decide to allow. Then you can simply disallow programs like IDA, rendering crackers helpless! As a side effect, you also get complete control over the user's computer, and you can use that power however you want. Everyone wins!

One last note: if you do decide to implement this, I recommend that your marketing department put a heavy spin on it. There'll probably be a bunch of jerks whining about "privacy" and "ownership" and crap like that. So you'll need a good name for this technology; the name has to sound like something people would want.

I think you should call it "trustworthy computing" (since "trusted computing" is already taken). Or maybe "secure computing".

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • You could also draw the popup message on a piece of paper, drive to the client, show it to him and then burn it. ^_^ only way to be safe! But seriously, key pairs should be created on the fly and never be stored anywhere. Even the server can create them on demand. – Corak Jun 11 '13 at 12:25
  • If the key pairs are only used for encryption, they don't have to be stored. If they're used for authentication (i.e., PKI), then they do. I do like the sneakernet approach! :) – Stephen Cleary Jun 11 '13 at 12:27
  • As Sam said, use hashing (and salting) for authentication. Not public/private keys. – Corak Jun 11 '13 at 12:28
  • It's not just authenticating I'm looking for, but securing the entire communication with the server from startup of the software to closure of the software. Regardless, I seem to be completely missing the point on asymmetric keys are about. –  Jun 11 '13 at 12:32
  • @Corak: Hashing and salting make sense for authenticating users by passwords. But PKI is fine for authenticating machines. – Stephen Cleary Jun 11 '13 at 12:34
  • If I try and put this into 'mind-code'; I receive a key from the server, and use this to encrypt my next message towards the server, correct? If this is true, I do need to temporarily store this key somewhere in a var to encrypt my next message? I suppose I really dont get it... :/ –  Jun 11 '13 at 12:35
  • @Evolution445: If you use TLS/SSL, your communication is secure; it's much better to use an existing well-tested TLS implementation than to write your own. Your question is more about how to secure the end user's machine (not the *communication*, the entire *machine*). And that really isn't possible. And it really *shouldn't* be possible. – Stephen Cleary Jun 11 '13 at 12:36
  • @Evolution445 - yes, you "save" it in memory (not in a database or the filesystem or anywhere like that). If you're afraid that someone will read the memory, then maybe something like [ProtectedData](http://msdn.microsoft.com/library/system.security.cryptography.protecteddata.protect.aspx) might work for you. But yeah, at some point, you have to just trust the user. After all, he trust you with his data, doesn't he? – Corak Jun 11 '13 at 12:43
  • So in my case, I'm posting data to the server's address using a WebClient object and a StreamWriter, and then reading the response of the server back, decrypting it and processing it. Would SSL work in this situation? I have no clue how to see SSL, is it like the middle man? Is this also PHP compatible? –  Jun 11 '13 at 13:20
  • `WebClient` has SSL support built-in; just use `https` instead of `http`. I don't know how to use SSL on the PHP server, but I'm sure it's supported. – Stephen Cleary Jun 11 '13 at 13:26
  • Let's see if I get it now then, if I simply change the URL to https, put an SSL certificate on the server and modify the client's code to only accept that certificate, everything I send is already encrypted and taken care of? Excuse my idiocy. :) –  Jun 11 '13 at 13:39