Risk Assessment

[Edward S. Marshall]

On Thu, 22 Oct 1998, Richard Lynch wrote:
> Did everything via telnet, since my ISP is 1000 miles away.

Any network in between can capture your packets. This means that if there
is a hostile (or compromised) network in between, your data could have
been captured.

This wouldn't necessarily need to be part of an attack against you
specifically; your key could be captured as a "lucky bonus" during a
compromise of an intermediary system.

Solution: use ssh for remote terminal access, instead of telnet. For
windows, you can use any number of products, such as stock ssh right up to
SecureCRT and others. This still implies a level of trust in the remote
system, but it ensures that an intermediary cannot collect data from your
connection.

> Generated keys using insecure memory, since I can't chown the binary to root.

"insecure memory"? It's only insecure if GPG doesn't clean memory properly
after generating a key (as other processes could then reuse the free()'d
memory later; protected memory spaces are exactly that: protected. Only
the process (or root) should be able to get at that memory space.

Unless I'm -really- missing something here? BUGTRAQ regulars, be kind. ;-)

If there really -is- an issue here, then solutions:

a) define a non-shared environment that you control for the purposes of
   this project (ie a machine -you- control), or

b) social solutions. Find a way to get the access you need to make
   changes, or find technical solutions to the "inconvenience issue" of
   the administrator setting up your software as needed, and arrange for
   social security of your data (through contracts).

> Exported all the keys and then the secret keys (--export-secret-keys isn't
> listed in -h, btw).

Reliance on security of the underlying operating system, and operater
cognizance of security issues. As long as you're aware that whoever owns
the system (hopefully you) can read the data, and can place explicit trust
in that, in addition to being aware of file permission issues, you're
fine.

But you've got an implicit level of trust with the administration of the
system you're doing this on. Don't put anything on the system you wouldn't
hand them anyway, unless it's password-protected before it gets on the
system.

> Elected not to use a passphrase, since it would be in a web-site script,
> which is publicly visible anyway.

Not much you -can- do here. This is a case where, if you want automation,
you must rely on the security of underlying operating system (and the
trust issue between you and the administrator) to save you.

Assume, however, that if you have a root compromise, -all- of your keys
are compromised. Your "break-in recovery" procedure should cover a means
by which you'll regenerate those keys and get them to the customer.

> Yeah, I *could* create a third script in a secure area to call that
> would spit the password out to the encryptor...  if I knew exactly how
> to do that...

Again, you're still relying on the security of the system anyway, so I'd
think you're better off with the original approach.

> Sneaker-netting the public and secret keyrings to my client's Windoze box
> and importing there, with insecure memory, and no real random device.

Lack of /dev/random shouldn't matter here, since they've already been
generated. Or am I missing something again?

However, you're now putting your security in the hands of Windows, and are
assuming you won't be compromised by the latest IE or Netscape exploit.
I'm assuming that this is a user's workstation?

Again, a trust issue with the underlying system operator, and their
intentions/competance.

Soltions: Define a trust level in the operator. Training, agreements, and
the customer's own self-interest can help here.

> Will be encrypting the data with insecure memory from a PHP web-script.

Again, insecure memory seems like an oxymoron to me, if post-processing
cleanup is done properly and you place trust in the system you're using. 

However, if memory serves, PHP operates as a part of the web server
(running code as the web server user, not via something like suexec). If
this is the case, a compromise of the web server itself is a compromise
for you.

Solution: Don't use PHP (or SSI, or anything of that nature) for
security-critical code. Use an external script (preferably something
compiled so that you can ensure proper memory cleanup before process
termination) which runs as -your- userid, so that you minimize the
potential for compromise (you still have a weak link in suexec, but that's
hand-auditable code; I know, I've done it ;-).

> Or not upgrading as often as I should.

This is a problem; it sounds like you have a trust issue with the
administrator. There's nothing here that can help you; your best bet is an
NDA with the ISP, or some sort of legal restraint, because there isn't
much of a technical means of protecting yourself here.

> The ISP gave me compiler access, but I still can't chown the binary to
> root, nor seriously expect them to do so every few days...  Would there be
> a way that your average paranoid ISP would be able to let me chown a
> specific file to root?...

Very unlikely, but a legally binding contract could ease their minds on
this, as well as yours. I am not an attorney, and this is not legal
advice; you should consult with your attorney on issues like this.

What is the root of the technical requirement here for root ownership (and
presumably suid permissions)? I must -really- be missing something here...

> E-mailing the encrypted order to the client.

If encrypted before transmission (assuming no breakdown earlier in the
chain), you're fine here. If there was any kind of breakdown earlier in
the chain (ie. the keys are compromised at any point), this serves as a
means of capturing the data (same problem as with telnet).

Solution: use ssh tunnels for transmission of the message off-site.

> The decrypting is all being done by a user on a windows box, who
> understands infinitely less of this stuff than I do, if you can believe
> that. :-)

This isn't necessarily a problem, except for the potential of a compromise
of their own system.

Solution: proper care and feeding of your users. ;-) This means training,
as well as configuration and upgrade assistance.

> I suspect I'm still not using the whole secret/public keys properly...  I
> generated all the public and secret keyrings on the Unix box (via telnet)
> and then exported them to the Windoze box...  In retrospect, perhaps it
> would have been better to generate the client's secret keyring on the
> Windoze box and export only the public ones from each to the other.  But
> I'd be trading the telnet/RAM-sniffing risk for the crappy RNG (hey, that
> stands for Random Number Generator, doesn't it?!) on Windoze.  My hatred of
> Windoze made me assume that it was still better to do it all on Unix.

In this case, it actually was a bad assumption. You can get more
randomness using /dev/random under Linux, but that is heavily offset by
the sheer number of potential vulnerabilities in generating the keys on a
shared, untrusted, remote system.

> I can redo the key generation, since I'm not trying to automate that.

Might not be a bad idea. ;-)

> Why do I get the feeling that there's a lot of folks out there that are
> just taking credit card orders on a "secure" server, and then transmitting
> them in clear-text via e-mail to their storefront POS credit-card
> machines?...  There *have* to be people other than me who are
> unable/unwilling to pay CyberCash rates...

Not us; we did the CyberCash thing, and provide it to our customers. It's
worked well, but you've still got a number of issues to work around, as
well as ensure that your own security is up-to-snuff.

Doing this via email would work well, but this kind of thing -only- works
when there is a specific level of trust in the systems you're using, and
their operators (both in terms of intent and skill), as well as a specific
level of trust in the security of those systems.

Without that, you've got no security. Technical solutions only go so far.

-- 
Edward S. Marshall <emarshal at logic.net>    http://www.logic.net/~emarshal/  -o)
------------------------------------------------------ ----- ---- --- -- -  /\\
Who'd have thought that we'd be freed from the Gates of hell by a penguin? _\_v

   Linux labyrinth 2.1.125 #9 SMP Sat Oct 17 14:46:24 CDT 1998 i586 unknown
        9:45pm up 5 days, 6:48, 5 users, load average: 0.01, 0.02, 0.00