Securing a database

[Bryan Olson]

kt83313 at gmail.com wrote:
> Thank you very much Bryan.
> It does look like this is out of my league.

As Peter Pearson noted, "It is out of *everyone's* league." And Peter 
used to work for Cryptography Research, a small company that scored as 
high in this league as anyone. Maybe you can advance the state of the 
art in DRM; but if so, you can probably make more money on that than on 
selling access to this particular database.

Stepping back, KT, you said that your company currently provides an 
on-line service backed by this database. Maybe you want to stick with 
that. Can you say what prompts you to look at offering off-line access 
to your customers?


I've spent most of my career, so far, as a cryptologic engineer, and 
I've seen similar problems. For example, the U.S. Postal Service has a 
database of valid addresses and address forwarding requests that can 
provide reasonable and valuable services, but that they are barred by 
law from generally exposing. Users are allowed to check the validity of 
a name-and-address, and if they have one, they're allowed to know if the 
addressee has forwarded it, and if so, to where.

At the time I got involved with the USPS's FASTforward system, they 
offered an Internet service, and an off-line locally-accessible product. 
The off-line product was a black-box system -- literally: a PC-class 
computer in locked black case, with hardened epoxy gumming up most of 
the interface ports. An open SCSI port answered legitimate forwarding 
requests, and the CD drive accepted encrypted updates to the database.

A similar scheme might still play, but there's no question that times 
have changed. Back then, the USPS system of locked black boxes made 
sense. Users numbered more than a hundred but less than a thousand, and 
the Post Office required agreement to a contract that protected 
individual addresses.


-- 
--Bryan