Securing Internal Transactions

K

Kiopa_Matt

Banned
May 13, 2011
5,216
52
0
Has anyone ever dealt with this? I need a way to secure internal transactions, or in other words, make them hacker / tamper proof. If you look at most say eCommerce or affiliate back-ends, it's basically just a database with a bunch of numbers, transaction rows, etc. If someone manages to root the server, they can just modify the transaction data however the hell they want. Keep them out of your server and database is the obvious answer, but say they get in via a 0 day exploit, or whatever.

I need a way so even if / when a hacker gets into the server, they can't screw with the transaction data, while keeping it user friendly. Any suggestions on this? I was actually thinking of taking a page out of Bitcoin somewhat.

What I was thinking was public / private key pair for each user (algo tbd). To keep it user friendly, store the private key on server, but encrypted via AES256 with the user's password + salt(s). When a user successfully logs in, it will decrypt their private key and temporarily store it (server or browser tbd) for the duration of the session.

All transactions are then hashed in a specific format, and signed with ECC by all involved parties. The transactions are then constantly verified & checked for proper signatures all throughout the software, which can be done with the public key. So although the user's private keys are online, they're encrypted via multiple iterations of AES256 with various different salts, and the decrypt password isn't anywhere online (user passwords = one-way SHA512 hash).

I'm not sure, has anyone else done something similar? If so, any suggestions?
 


If the data is on the server and the server ever decrypts the data, an attacker with enough privileges can access the data.
 
Hey Matt,

What you have in mind is "good enough". However the biggest problem is if the attacker is intelligent, if/when he roots the server he will install something to capture the user's private key from memory, during a user's session. From then on he can use it to sign/create/whatever his own transactions.

Ultimately anything you do will be compromised if the attacker gains access to the server. So you should focus all your attention on hardening the server. The NSA has written a nice 200 page guide on this that should get you started:

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Aside from that, you can also use software tamper proofing solutions to prevent the hacker from inspecting your software while it is running, and a white box crypto library to protect the user's keys even while the software is running. However both these things take months to implement correctly, and end up costing 6 figures a year in licensing fees. Usually you only want to use these if your software will be executing in crazy hostile environments, or you have crazy contractual requirements.
 
  • Like
Reactions: Kiopa_Matt
You must log in or register to reply here.
Top Bottom
Back