Jump to content

openssl private key


dlf1987

Recommended Posts

After hours of finally making a public and private key with openssl, im having trouble figuring out the best way to pull the private key from my local computer. I have the public key on the webserver and i have the private key on my local computer.

 

I thought about just saving a bookmark on my computer like...

 

https://mysite.com/admin/login.php?private={-----RSA PRIVATE KEY-----} and then have the page save the $_GET['private'] in a cookie.

 

But that doesnt sound very safe. But whats the chances someone could break into my webserver and steal the public key... then break into my local computer and steal the private key from my cookies...

 

Is there a better way to do it?

 

PHP / 5.3.6

IIS7

Link to comment
Share on other sites

ive used openssl to encrypt customers personal data.

 

What ive done is, made a html file that is on our office server (not webserver) and is shortcut'd to employees desktops...

 

<form method="post" action="https://www.mysite.com/admin/login.php">

    <textarea name="private_key" cols="75" rows="20" style="display:none">{-----RSA PRIVATE KEY-----}</textarea>
    
    <input type="text" name="private_pass" value="****" style="display:none" />
    
    <input type="submit" name="postBTN" value="mysite Login" style="font-size:20px;" />
    
</form>

 

I have the employee open the file above and click the submit button, which posts the form data to the admin login page. The login page puts the post data in a cookie. The employee then enters their admin username and password.

 

The html file isnt needed to login, but is needed to see customer personal data on certain pages of the admin section. If a employee tries to see customer data without using the above html file, theyll see "access denied" in place of the customers data.

 

I didnt make this to keep out certain employees, i made it this way so that if someone outside the company got a hold of admin login info or if the webserver/mysql was hacked and the data stolen that they wouldnt have the private key, just the public.

 

Seems to be working great right now.

 

As far as i know the only way a hacker could decrypt the info would be to get the private key from our office and get the public key from the webserver. seems unlikely.

Link to comment
Share on other sites

What you've done is bizarre, and it doesn't seem you understand public key crypto.  Private keys are not to be disclosed.  Based on your description I have no idea whose key is being used for what or where. 

 

Here's the 2 basic use cases for public key/private key crypto:

 

- I sign something with my private key and give you my public key.  You will be able to decrypt the data using my public key, and in doing so, you know that the data came from me.

- You have my public key and want to send some data securely to me, so you encrypt the data with my public key.  I am the only one who will be able to decrypt the data because only I have the private key.

 

Everything that is based on pk crypto is a variation of these 2 uses.  There is no use case that involves passing a private key to someone.

 

So a few things: 

 

-webserver is hacked.  Well I have full access to your filesystem and the mysql database as root.  What is it that I can't do?

 

When I asked what you were trying to do, I was hoping for a list of goals/objectives, rather than a description of what you think you've accomplished.

Link to comment
Share on other sites

-webserver is hacked.  Well I have full access to your filesystem and the mysql database as root.  What is it that I can't do?

 

They cant decrypt the encrypted data in the mysql database. Because they dont have the private key to decrypt with.

When i talk about openssl, im not talking about https. I used openssl to literally encrypt the data (just like using mcrypt) and the hacker would see gibberish instead of the original data.

 

My original question wasnt very clear.

 

- You have my public key and want to send some data securely to me, so you encrypt the data with my public key.  I am the only one who will be able to decrypt the data because only I have the private key.

Thats sort of what i did. Except i used the public key to encrypt the data and stored it in the mysql db. Employees will be the only ones able to decrypt the data because they have the private key.

 

The reason why im using public/private keys to encrypt/decrypt data is because if a hacker was to gain full access to the web server, mcrypt is pretty worthless since the key would be stored on the webserver within the PHP code and they'd have everything they needed to decrypt the data.

Link to comment
Share on other sites

So if I understand you correctly you used just the crypto portion which is the exact same libraries as those used by mcrypt.

 

requinix pointed out already a major issue with what you're doing, and it's really no different than passing some ciphertext with every connection.

 

-If i can get access to any of the workstations I have access to the data

-Even with this system in place, if I get access to the server, I can put capturing in place that gets the decrypted data.

-I'm assuming you are backing up all these key pairs someplace, since the most likely thing to happen is that the harddrive will die in one of the workstations or the server.  If one of the workstations die, and you lose the key, that data can't be decrypted.

 

If all of this convolution has been designed because this application is in service of an industry that has some form of regulation in place, then I guess it's understandable, but what would make more sense is that there would be a client application that was configured with a private key and had a corresponding public key on the server.  The save routine for a row would use the corresponding client public key to encrypt the data before storing it in the database.  The Private key would never be sent.  Encrypted data in the database can not be decrypted by anyone except for the client that sent it.  The client application would then use the private key to decrypt the data whenever it would need to be viewed. 

 

And of course the danger of losing the private key is the same -- it is catastrophic total loss of all encrypted/stored data for that client.

 

 

Link to comment
Share on other sites

It also means only that one employee can ever get the information associated with a customer...

Not true, we have multiple employees able to access the data this way, all employees have the private key.

 

After making the openssl script, a couple days later i stumbled upon phpcreditcard.com. I bought it to see if they were doing the same thing i was, and they were, except that they used a desktop app that had the private key. But i didnt want employees to have to open the app and copy/paste the decrypted data when needed. So instead of using the app, i send the private key in a cookie so they can view the decrypted data directly on the website.

---------------------------------

 

At this point im not really asking for help, im pretty happy with the way i got it, except that the private key is stored in employees browser cookie.

 

But heres the code incase your interested.  :)

 

CREATES KEYS

function create_keys()
{
$configargs = array(
	'config' => 'C:/wamp/bin/php/php5.3.5/extras/openssl/openssl.cnf',
	'digest_alg' => 'md5',
	'private_key_bits' => 2048,
	'private_key_type' => OPENSSL_KEYTYPE_RSA,
	'encrypt_key' => true,
	);

$dn = array(
	"countryName" => "US",
	"stateOrProvinceName" => "STATE",
	"localityName" => "CITY",
	"organizationName" => "WEBSITE",
	"organizationalUnitName" => "WEBSITE",
	"commonName" => "WEBSITE",
	"emailAddress" => "EMAIL"
);

$privkey = openssl_pkey_new($configargs);	
openssl_pkey_export($privkey, $pkeyout, "PASSWORD", $configargs);
$pubkey=openssl_pkey_get_details($privkey);	

echo $pubkey["key"]."\n\n";
echo $pkeyout;
}

echo create_keys(); // Once i see the keys that have been output. I copy/paste the public key into a "public.pem" file. And copy/paste the private key in the local server file at our office.

 

ENCRYPT WITH

function encrypt_card($data)
{
$public = openssl_get_publickey('file://C:/inetpub/vhosts/mywebsite.com/httpdocs/includes/public.pem');
openssl_public_encrypt($data, $encrypted, $public, OPENSSL_PKCS1_PADDING);
return base64_encode($encrypted);	
}

 

DECRYPT WITH

function decrypt_card($data, $private, $pass)
{
$data = base64_decode($data);
$private = openssl_get_privatekey($private, $pass);
openssl_private_decrypt($data, $decrypted, $private, OPENSSL_PKCS1_PADDING);
return $decrypted;
}

echo decrypt_card($mysql_data['sensitive_info'], $_COOKIE['private_key'], $_COOKIE['private_pass']);

 

Link to comment
Share on other sites

Well, I'm glad gizmola is here. Frees me up to look at your design :)

 

Not true, we have multiple employees able to access the data this way, all employees have the private key.

Then what's the point of encryption if everybody has the same private key? Why bother letting them hold onto it? Cookies can expire, and computer "cleaning" software can delete them. So if that happens, how does the private key get back into the employee's metaphorical hands?

 

Also, if you're putting the key in the cookie, that means the server has it. Which means compromising the server gives both public and private keys. Which means the encryption is as useless as you say other schemes are.

Link to comment
Share on other sites

I think we've explored this as much as possible.  I'll stick by my two comments which are that this is a very odd design, and employs pk crypto incorrectly.  The other issue with this thread is that it's misleading in that it has almost nothing to do with the OpenSSL library.  Although the problems being solved were never articulated in the thread, I assumed based on statements made by the OP that one of the main goals was having some rows in the database that are encrypted differently from others, but as it turns out, everyone who accesses the system has the same key.

 

I've pointed out repeatedly, that when users are accessing the application, the application passes the key to the data, and so to his point, there is some additional level of security in that the private key is not being stored on the server, however, if I compromise the server all I need to do is intercept the key being passed, which is exceedingly simple, since it's coming in a cookie, since i can easily get apache to log the cookies.

 

Overall, it seems that the OP is happy with his design, and I feel I'm just repeating objections.  I'm appreciative that he he shared his encrypt/decrypt code, but I feel it important to note that you can only safely encrypt from 50-100 characters of data using these routines.  There's no difference really between using this method or using mcrypt with an encryption key.

Link to comment
Share on other sites

i guess i could store the private key in a file on a local computer and create a local script that querys the webserver mysql db for the encrypted data and decrypts it locally, so that its not passed through cookies.

Link to comment
Share on other sites

i guess i could store the private key in a file on a local computer and create a local script that querys the webserver mysql db for the encrypted data and decrypts it locally, so that its not passed through cookies.

 

Yes if the Private key remained on the workstations then whenever data was saved to mysql the server could use the public key to encrypt it, and even if the server was compromised, someone without the private key would not be able to decrypt it.  With a fat client application you have many options including having all the encrypt/decrypt happen on the client and just using the server for storage of data.

 

The question I would ask is this:  you allow the client workstations to have these keys.  If your entire concern is that you don't want a box sitting on the pubic internet, then why not configure a private server, and use a vpn technology to control access to it, and then you could just concentrate on application functionality? 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.