Flags For RVM Ruby

Using macports-installed extras:

LDFLAGS="-L/opt/local/lib -arch x86_64" CPPFLAGS="-I/opt/local/include" rvm install 1.8.6-p399

activerecord-sqlserver-adapter woes

When installing the activerecord-sqlserver-adapter on CentOS/Redhat, the instructions posted here generally work well (including the bit about using tiny_tds instead of ODBC).

The only missing piece is that you must also install the ruby-static package along with those mentioned. I believe I found this in ELFF or EPEL. No problem.

Ruby on Windows

Ugh.

File.new

Spent about three hours tracking down weirdness with the Ruby File class on Windows. My unit tests create several files, as does some of the code I'm working on. All the tests work fine on my Mac, and the tests all clean up after themselves just fine. Deploy it all to Windows, and all of a sudden tests are failing and there are a ton of test files/folders leftover. Couldn't leave well enough alone.

Turns out that File.new on Windows leaves a handle open. Maybe it does on the Mac, too. Didn't dig in. All I know is that on Windows I had to explicitly call close() on each file to ensure that there weren't any handles laying around, but the Mac worked fine without it. This is, incidentally, different from Java. In Java a File object instance is so abstract that the file just has to exist.

Tempfile

Great library. Did everything I needed...until I discovered, like some other poor schlebs, that Tempfile operates in ASCII mode exclusively. All my writes were getting jumbled up and truncated. After playing around with FileTemp, I ended up abandoning the use of a temporary file altogether, not having found a very good solution, and not having time or the inclination to try my hand at fixing it.

Securing Data at Rest, Pt. III

Evaluated GPG for encrypting audio files. It worked very well, and fast enough for in-band decryption, at about 0.3 s / file, on average on my dev box. Unfortunately, GPG seems to have poor library support in a deliberate attempt to subvert malicious users.

I once mistakenly thought of GPG as an encryption total package: custom encryption, key management, and key trust management. Now I see it really as a key trust application layered over existing standard compression algorithms, with a key management front end. Given that we will not be sharing keys, key trust is not at issue, and it really makes GPG seem like overkill. Hence, my decision to spike encryption of transcripts using Java's Cryptographic Extension.

Since I have the option with the JCE, I'm interested in speedy decryption, which would mean using a stream cipher. JCE provides stream ciphers, but stream ciphers have weaknesses, especially if you happen to reuse a key. If an attacker got her hands on the ciphertext for which she has the plaintext, she can derive the key stream. As a result, the recommended practice is to use a block cipher that supports a mode that behaves like a stream cipher (e.g., AES in CFB mode).

For reference, tests yielded the following results:

• Block cipher: 15ms encrypt / 125 ms decrypt
• Block cipher as stream: 63 ms encrypt / 78 ms decrypt
• Stream cipher: 31 ms encrypt / <>

Next is the issue of protecting secret data. Security best practice is to not store keys in a config file. Your options are in a separate file/registry, encrypted/not. The idea of encrypting the keys again seems like the quickest way into the 9th circle of key hell. This made me look at LSA secrets and the DPAPI.

LSA secrets is the first choice, because it stores the secret data in the profile of the running user account, making storage not my problem. Accounts indicate that this API is complex, has a maximum number of secrets that can be stored, and is required to run with administrative privileges--all cons, as far as I'm concerened.

DPAPI sounds like salvation, but for the fact that it's at end of life (MSDN advises using the .NET framework instead) and I'm responsible for storing the encrypted blob, and interop with Java will take some work, likely involving JNA to export the DPAPI methods. If I have to store the keys, I might as well do it some way more convenient.

Securing Data at Rest, Pt. II

Talked to Jesse last night. Asked him about our situation and options. He had two suggestions.

First, if we go the appliance route, we should look at Decru (the top of the line, which Net App OEMs), Brocade, or Cisco. He says the Decru would be around 40K each, with three necessary to form a quorum and prevent any key loss. He estimates the Cisco at around 20K, but suggested that we price it ourselves. Due to the great cost for a company as small as ours, he advises us to bundle the cost of these appliance with the addition of a client contract.

Second, his suggestion is that perhaps the insurance industry is not as interested in the encryption of intermediate storage, but more interested in the encryption of archival data. In that case, we could get a tape drive that encrypts on write. This would be the most economical option, in his opinion.

I briefly considered homegrown in-band encryption on an additional server on our network, but he pointed out that that's basically just creating your own appliance. Good point. I'm guessing the main constraint governing any decision here will be price.

Securing Data at Rest

There are hardware and software options available. Basic options include:

• Storage System - secures data at rest, least secure, hardware / hosting implication, easiest to implement
  
• Network Appliance -mid-level security, secures data in-flight, lowest barrier to entry, cost-effective, doesn't affect current storage infrastructure, can be bypassed if necessary, one required for every 1-2 storage devices, good short-term solution but may not scale
• Host-based - most secure, requires installation on client computer

Notes:

• Don't encrypt everything. Figure out what's really important and only encrypt that.
• No matter what solution you choose, use centralized key management.
• Some level of automation of key requisition, backup, etc., should be required.
  
• An API doesn't hurt, either.

• A pretty good intro article.
• Encryption Strategies Whitepaper, 10/2007
• Securing Data at Rest, 2008 Sun Labs Open House