Ripple API - general security best practices for private keys

[jetbrzzz]

Just looking for some devs or advanced users to chime in on some best practices for general private key security while using RippleAPI on a local server.  Was going through xrpl.org docs and it's in there that commandline is less secure than, say, JSON-RPC because of things like shell histories and maybe process logging, etc., which I agree with generally.  Trying to avoid things like cutting and pasting private keys into commandline scripts to mitigate things like keyboard/clipboard/history loggers, even if just a little.  I've been using Linux bash and piping things into jq to process JSON in order to sign and submit transactions; are devs hardcoding private keys into JavaScripts and then just encrypting those files? Pretty sure hard-coding private keys in anything like a script is a no-no, but I could be missing something.

In terms of eventually automating my transactions, I could think of a couple ways, like referencing decrypted private key files, running your scripts then deleting/re-encrypting your private keys.  I'm picking up javascript at the moment and guess I'll end up switching over to node.js to do transactions instead of through bash and bash scripts; seems like the Ripple API was designed with that in mind.  I'm just using Linux command-line now cause I'm already familiar with bash and jq.

Generally speaking, how are y'all managing private keys while using commandline/JSON-RPC/Websocket?

[JASCoder]

Hi friend, this is a very important topic, glad to see anyone taking it as seriously as it deserves.

My background includes supporting enterprise level PCI compliance, and practices. But those onerous encumbrances are prolly a bit excessive in your case, so I'll just make a few general points in response...

1. NEVER have your crucial data stored in a cleartext form, either in a database or in a script/json type file.
2. NEVER type out a phrase for a potential keylogger to intercept. Ideally use an automated process that purges the paste buffer (like with a password app such as https://www.keepassx.org/ or others you trust are safe to use).
3. An easy trick you can code for, is to "arm" a persistent process with the secret values (pasting it at a manual launch time), and code it to provide the secret to a localhost only query. I have also used the shmem capability available in unix systems, this is what Apache uses for interprocess communications. 

Cheers.

[jetbrzzz]

6 hours ago, JASCoder said:

1. An easy trick you can code for, is to "arm" a persistent process with the secret values (pasting it at a manual launch time), and code it to provide the secret to a localhost only query. I have also used the shmem capability available in unix systems, this is what Apache uses for interprocess communications. 

Cheers.

Does it matter pasting/passing an unencrypted private key into a persistent process; like after it's stored, it's as safe as it could be basically? Not familiar with shmem but I'll look into that too. I thought about scripting something that pulls private keys from a .gpg file automatically too.

Thanks for the other ideas, 'specially 2. Was wondering how I could 2FA my local machine, since I already have iphone 2FA set up on my crypto-exchange account. I've heard horror stories about Ledger Nanos etc, I'm just as well off getting a yubi key and keeping everything on my own machines. Appreciate the help!

[Dogowner5]

Another option is to make a blob on a totally and forever offline PC and then using QR code into a online phone wallet for submission.

Toastwallet has that functionality built into it.  But you can also just do it manually.  Just spitballing options.

[jetbrzzz]

1 hour ago, Dogowner5 said:

Another option is to make a blob on a totally and forever offline PC and then using QR code into a online phone wallet for submission.

Toastwallet has that functionality built into it.  But you can also just do it manually.  Just spitballing options.

I'm kinda paranoid about 3rd party anything tbh, as convenient as they make life.  For smaller petty cash/daily wallets I could go with it but not for long-term high value holdings; I be wary. I've heard of people buying Nanos that were opened and had hardware replaced pre-purchase, or buying used Nanos on ebay and not resetting the master seed; adds a lot of attack vectors.  Haven't heard of backdoors in something like Toastwallet, but where there's money, there's that.  Add that whole TikTok thing (I think) where iPhone caught it logging clipboard inputs every 3 keystrokes, seriously wth.

I thought about that, signing all my tx on a dedicated offline machine and piping the blob into qrencode to be scanned or bulk submitted. You'd have to figure out a way to pull the current sequences to that offline machine right (other than just manually looking it up on xrpl-explore )? I'm talking about if I were to set up offline automated bulk transaction signing on a single account.

[SimpleXRPTools]

25 minutes ago, jetbrzzz said:

You'd have to figure out a way to pull the current sequences to that offline machine right (other than just manually looking it up on xrpl-explore )?

I've only got experience using Javascript in the browser so I can't say what will work for you, but in my process, you 'prepare' the transaction online (only requires the public XRP address, automatically getting the next sequence number) and then you copy the 'prepared' transaction to an offline PC for signing. Once signed, there's no chance the XRP secret/seed could be extracted from the blob.

I then copy the 'signed' transaction back to an online PC and submit using https://xrpl.org/websocket-api-tool.html#submit

[jetbrzzz]

9 hours ago, SimpleXRPTools said:

I've only got experience using Javascript in the browser so I can't say what will work for you, but in my process, you 'prepare' the transaction online (only requires the public XRP address, automatically getting the next sequence number) and then you copy the 'prepared' transaction to an offline PC for signing.

Ah, makes sense that way, I've been manually prepping tx completely offline up to this point. Are you just copying the prepped tx to a USB or something else?

I could see having a setup where I could have one offline and one online machine connected through a private, secure LAN and just pass prepped tx and signed tx back and forth that way.

[jn_r]

41 minutes ago, jetbrzzz said:

Ah, makes sense that way, I've been manually prepping tx completely offline up to this point. Are you just copying the prepped tx to a USB or something else?

I could see having a setup where I could have one offline and one online machine connected through a private, secure LAN and just pass prepped tx and signed tx back and forth that way.

Either way you still have to hold the secret on a running machine. If your machine only has outgoing connections and the firewall to inside is completely closed, would it make a difference?

And if your transacting system is compromised, couldn't it just be prepared to submit all XRP to an address of choice? 

[JASCoder]

15 hours ago, jetbrzzz said:

Does it matter pasting/passing an unencrypted private key into a persistent process; like after it's stored, it's as safe as it could be basically? Not familiar with shmem but I'll look into that too. I thought about scripting something that pulls private keys from a .gpg file automatically too.

Thanks for the other ideas, 'specially 2. Was wondering how I could 2FA my local machine, since I already have iphone 2FA set up on my crypto-exchange account. I've heard horror stories about Ledger Nanos etc, I'm just as well off getting a yubi key and keeping everything on my own machines. Appreciate the help!

shmem in concept is essentially a block of allocated memory - much like an array declaration in a process - which can be "shared" with other processes. This mechanism enables interprocess communication, and the complexities of properly managing its usage. I once used it in a custom Apache module I wrote to track and tabulate consumed bandwidth of all IPs requesting a site's content, and cutting off abuse of malicious clients.

Just to be clear, when you wrote "after it's stored" - that meant stored in memory of the persistent process, right? 

In the past I've coded and built out systems which provided secret keys on demand via API calls (auth'd and locked to only whitelisted IPs of course) from an "armed" persistent server process. The point is that the cleartext NEVER be scored to a database nor a file. Extra points to encrypting the value in its stored-in-memory variable to a randomly generated salt - just to guard against a local process reading its shmem block, or parsed out from a post-mortem core dump.

See what working under PCI constraints does to your level of paranoia - lol

Re extracting hidden data from a .gpg file - using something like steganography is very creative, but I'd still want the message encrypted, and any hack of an environment would include the source code of your scripts and ancillary files. You want to design security to survive total infiltration, like if someone stole your laptop and mounted the drive as an external filesystem. This is why ephemeral storage of secret cleartext is the only viable solution.

I really like the IRONKEY "thumb-drive" (now owned by Kingston). Originally developed under contract to the DOD, it's about as safe a storage as it comes. Contents are encrypted by the hardware, which is hardened against physical intrusion, and "self-destructs" the contents upon ten consecutive wrong passwords (it will prompt you with your original hint phrase). This could be leveraged to provide both backup and redundancy of precious data.

Cheers and good luck m8

Edited August 22, 2020 by JASCoder

[jetbrzzz]

1 hour ago, jn_r said:

Either way you still have to hold the secret on a running machine. If your machine only has outgoing connections and the firewall to inside is completely closed, would it make a difference?

And if your transacting system is compromised, couldn't it just be prepared to submit all XRP to an address of choice? 

I'd have to have at least a port open between the two to pass the prepped tx from the online machine to the the offline machine for signing. Maybe SSH in through the LAN  or something.

Do you mean a hacker could submit all my XRP to the address of their choice or that I should program the system to only be able to send XRP from my account to another account I control? There are trustlines and disable-from-all-except-whitelist type flags for XRP addresses, I'm looking into those too.  Banks use things like that so people they don't know can't just deposit money in their accounts, part of KYC compliance I think.

There might be a reverse of that, where XRP accounts can only send to known/whitelisted accounts. Combined with a Regular Key, which can only do transactions and not admin changes on the accounts, it would be a good basis of security.

[jetbrzzz]

59 minutes ago, JASCoder said:

Just to be clear, when you wrote "after it's stored" - that meant stored in memory of the persistent process, right? 

In the past I've coded and built out systems which provided secret keys on demand via API calls (auth'd and locked to only whitelisted IPs of course) from an "armed" persistent server process. The point is that the cleartext NEVER be scored to a database nor a file. Extra points to encrypting the value in its stored-in-memory variable to a randomly generated salt - just to guard against a local process reading its shmem block, or parsed out from a post-mortem core dump.

See what working under PCI constraints does to your level of paranoia - lol

Re extracting hidden data from a .gpg file - using something like steganography is very creative, but I'd still want the message encrypted, and any hack of an environment would include the source code of your scripts and ancillary files. You want to design security to survive total infiltration, like if someone stole your laptop and mounted the drive as an external filesystem. This is why ephemeral storage of secret cleartext is the only viable solution.

I really like the IRONKEY "thumb-drive" (now owned by Kingston). Originally developed under contract to the DOD, it's about as safe a storage as it comes. Contents are encrypted by the hardware, which is hardened against physical intrusion, and "self-destructs" the contents upon ten consecutive wrong passwords (it will prompt you with your original hint phrase). This could be leveraged to provide both backup and redundancy of precious data.

Cheers and good luck m8

Yes, that's what I meant, but it seems like there is still the possibility of getting the key from a local process if the key was stored to the shmem block in plaintext, via process logging, which is why you mentioned encrypting/salting the value I'm guessing. 

I get the paranoia, if someone actually steals my laptop, then yes, I'd be f'd if my .gpg file was on there; I guess they could eventually crack a .gpg file for the keys. Or like you said, do a core dump, etc looking for plaintext keys right after the point in time in my script where it decrypts the .gpg files and passes it to the next line of code unencrypted.

I'll probably end up doing something like your Mission: Impossible self-destructing 2FA thumb-drive and multi-signing on my XRP account. Appreciate all the good ideas and beta!

[jn_r]

3 minutes ago, jetbrzzz said:

I'd have to have at least a port open between the two to pass the prepped tx from the online machine to the the offline machine for signing. Maybe SSH in through the LAN  or something.

Do you mean a hacker could submit all my XRP to the address of their choice or that I should program the system to only be able to send XRP from my account to another account I control? There are trustlines and disable-from-all-except-whitelist type flags for XRP addresses, I'm looking into those too.  Banks use things like that so people they don't know can't just deposit money in their accounts, part of KYC compliance I think.

There might be a reverse of that, where XRP accounts can only send to known/whitelisted accounts. Combined with a Regular Key, which can only do transactions and not admin changes on the accounts, it would be a good basis of security.

You can build extra security on the 'offline' machine by putting restrictions on basis of the content of the transaction, like a max amount, only allow orders on a specific orderbook or only allow sending to accounts on a whitelist. The possibilities are limited and they also limit the possibilities of your automated system, but that would help.

On the other hand if your 'online' system gets compromised (which is not running a service, i.e. no ports open) why would the 'offline' system (which is running a service) not be compromised - via the 'online' system..

If you have no problem manually providing a password every time the service on the online machine restarts, you could also encrypt the key with some standard solution and unlock the key with a password when you start the program.

[SimpleXRPTools]

8 hours ago, jetbrzzz said:

Are you just copying the prepped tx to a USB or something else?

Yes, I just use a USB to transfer info back and forth. My online PC is Windows but my offline PC is Linux. The likelihood of viruses/malware being transferred to the Linux PC are acceptably low.

As an extra layer of security, I only submit transactions via https://xrpl.org/websocket-api-tool.html#submit

I don't think I can claim 100% safety but the risk is extremely low.

[jetbrzzz]

25 minutes ago, SimpleXRPTools said:

Yes, I just use a USB to transfer info back and forth. My online PC is Windows but my offline PC is Linux. The likelihood of viruses/malware being transferred to the Linux PC are acceptably low.

As an extra layer of security, I only submit transactions via https://xrpl.org/websocket-api-tool.html#submit

I don't think I can claim 100% safety but the risk is extremely low.

I wasn't aware of that tool, very good to know since I've been doing everything in bash. There's no such thing as 100% secure, if someone wants it bad enough there's a way, but like you said, as long as the risk is low enough you just gotta live life.  And for a long-term, high-value, cold wallet storage the minor USB hassle is acceptable for monthly or annual transactions.