[OT] Re: RSA implementation, please comment.
- From: Martijn Lievaart <m@xxxxxxxxxxxxxxxx>
- Date: Wed, 2 Jul 2008 10:26:03 +0200
[ This has nothing to do with Perl. If you want to continue the
conversation, find an appropriate group or take it to mail ]
On Tue, 01 Jul 2008 17:24:08 -0700, Rob wrote:
Although I'll try to improve on your security, you'ld best take a step
back and look at the whole problem again. Storing the creditcard details
on a separate server is actually a very good idea, because a server with
less functions is easier to secure.
So set up a web front. This web front uses a well defined and secure
channel to talk to the credit-card-details server. This must go through a
firewall that allows nothing else from web front to credit-card-details
server.
The protocol should be custom defined, well implemented by someone used
to secure coding and only allow storing the details, not deleting,
altering or retrieving them (some retrieval may be necessary, but never
the card number). If alteration is a must, this must be very carefully
implemented, probably by sending a new card record and storing a link to
the new record, not deleting the old record. Avoid the temptation to use
a raw database connection. Even when the database itself is properly
secured (which it should be), you take away one layer of defense and rely
on the database security alone, which is notoriously hard to get right.
The clients use well defined and secure channels to talk to this server.
Start with allowing only access from specific IPs. Using certificates on
smart cards is a common way to further secure this access. Also pay
attention to administrative access, this should be even more secure.
Only with this setup you can be reasonably secure. Public webservers get
hacked way more often than dedicated servers, by splitting your
functionality between a public webserver and a dedicated backend server
you can avoid damage when your webserver gets hacked.
And pay attention to backup! The number of times I've seen setups like
the above, all computers secured, behind a dedicated firewall, all
perfectly according to the book, only to find that the backup network
ties them all together again without a firewall in sight.
If you have all the above right, you can start implementing details.
I believe that this solution is secure because the private key password
is never saved on the server. A hacker would have to gain access to an
authorized user's PC to gain the password. I am not sure how difficult
it is to crack a 256 bit private key with a 63 character pass. There is
plenty of documentation on how hard it is to brute force the entire key,
but not much I could find on the password.
Brute forcing a 63 character password is doable, although very time
consuming. For most e-commerce, I would say it's acceptable if there is
no other solution.
But are your users really going to enter a 63 character password? If no,
the password is shorter and easily brute forced. If yes, users will store
the password which can be regained by an attacker.
Here's an alternative.
- Don't store the private key on the server. Use the public key to
encrypt the card details.
- Every client gets a smartcard for the decryption (or a HSM, but those
are costly).
- Use a pin to protect the smartcard (commonly called a pin in the
context of smartcards, but often can actually be a pass phrase)
(actually, you use a pin to protect specific items on the card)
- Store the private key only on the smartcard. Make sure the key can only
be used for decryption and cannot be retrieved.
- Use an application client side to drive the smartcard (can be a Java
applet).
With this scheme, an attacker can crack the server, but cannot get at the
credit card details.
Why is this more secure?
- Private key gets only stored in smartcard, so -- if properly implemented
[2] -- impossible to copy.
- Brute forcing smartcard PINs is -- if properly implemented --
impossible. The card locks up after a number of wrong guesses.
- Man in the middle attacks are impossible.
- hacking the client computer does not immediately give an attacker full
access, he still needs a smartcard (if client is hacked, consider the PIN
compromised)
But this scheme has an obvious weakness. If a smartcard gets stolen,
together with the PIN, your borked. To get around that:
- If a smartcard gets missing/stolen, it must be reported immediately.
Draw up a contract that says the holder is responsible for damages
occurring through misuse of their card.
- Use a certificate per smartcard.
- The certificate gets stored on the server, together with a status flag
(inactive, active, stolen, revoked) (ldap is very good at storing
certificates).
- The private for the certificate key is stored on the smartcard,
protected by pin.
- This certificate is used to identify the client, so they don't have to
log on using user name+password (side effect, but makes it much more
useable for the client). Most (all?) webservers can do this very easily
and most (all?) webbrowsers support this.
- The certificate and private key are used to generate a session key. If
properly implemented, only the server and the smartcard know this key.
The client software doesn't know this key at all. However, you might want
to compromise here a bit.
- The encrypted credit card details are encrypted again by the server
with the session key and send to the client.
- The client uses the smartcard to decrypt the encrypted-encrypted credit
card details, then uses the smartcard again to decrypt the encrypted
details.
Why is this more secure than my first scenario?
- If a smartcard+PIN gets stolen, you have a fighting chance to revoke
the certificate before it is used.
However, this still leaves the attacker the possibility to crack the
server, get the single-encrypted details and use a stolen smartcard+pin
to decrypt the data. So the scheme should be enhanced:
- Protect the common private key not only by pin, but also by another
mechanism. The cards certificate should be presented to an authentication
server[1] (not the same server as the one storing the creditcard details)
which gives back a key (unique for that card) that can be used to unlock
the common private key. If you implement this you can even drop the pin
protecting the common private key.
Now an attacker has to hack two servers, and steal a smartcard+PIN.
(Aside from doing a lot of work once he has these).
[ Disclaimer, only thinking about this for an hour makes the above
suspect. I may very well have overlooked something, in fact I probably
have. I just want to give directions, but you have to learn to swim
yourself. ]
There is another scheme, less secure, but easier implemented.
- Again, use another authentication server. Use certificates for clients
to log into this server and set up a secure communication channel.
- The common private key is stored on this authentication server and send
to the client over this secured channel.
- Client uses private key to access credit card details.
HTH,
M4
[1] Authentication servers are easier to secure, but they should be very
secure. Use a dedicated server, behind a dedicated firewall. Pay
attention to physical access.
If you need to administer remotely: use a public/private key pair to
grant access, preferably using smartcards, and only from certain IPs.
[2] "If properly implemented" is actually quite hard to ascertain. Never
assume, test, test, test. Build specific testframeworks[3] to be sure.
Assumption is the mother....
[3] I once replaced the Windows smartcard DLL to see what went on under
the hood. Found one bit that was wrong, which made the whole security of
that application worthless. Luckily this was in the security testing
stage, so it could be rectified before deployment.
.
- References:
- RSA implementation, please comment.
- From: Rob
- RSA implementation, please comment.
- Prev by Date: Re: RSA implementation, please comment.
- Next by Date: Re: My c code has stopped working: PL_errgv NULL?
- Previous by thread: Re: RSA implementation, please comment.
- Next by thread: FAQ 8.33 Is there a way to hide perl's command line from programs such as "ps"?
- Index(es):
Relevant Pages
|
