PHP & GPG RULE!!!

[Richard Lynch]

[apologies for X-post: at least it's Bcc: so y'all don't spam each other...]

YES!!!

I finally got my PHP (a way-cool cgi-writing language <www.php.net>) script
to talk to GPG (Gnu Privacy Guard - a freebie PGP alternative
<www.d.shuttle.de/isil/gnupg>).  It's not pretty enough to publish yet, but
soon.

NOTE:  GPG is currently ALPHA software.  Use it at your own risk.

First and Foremost:  Big Up to everybody on both mailing lists who helped
out (or even just put up with) this wordy/nerdy Unix/gpg ignoramous over
the course of this saga.  It is *MUCH* appreciated!!!

The goal was to allow low-budget low-volume SECURE "e-commerce" (sorry)
using OpenSource software to get data safely to a Point-Of-Sale terminal,
thus "leveling the playing field" for small business-oriented web-sites.
No software to buy.  No setup fees, monthly fees, or percentage of sales to
pay to your ISP to run credit cards through their system.  Use your
existing credit card authorization system, order, and shipping procedures
in place.

Okay, enough market-speak for the year.  On to techie details!

I'd appreciate some feedback on whether or not you would be interested in
using such a system, so I know how hard to make it easy for you, instead of
just hacking it for myself. :-)

The basic model:

One-Time setup:
---
On a SECURE machine (Windoze or Unix) via CONSOLE input (or SSH):
o use gpg to generate a public/private key-pair
o export the public key
o import the public key on the secure web-server
  [Yes, you *DO* need a secure web-server...many ISPs include this these days]

On-Going transactions:
---
On the secure server, use a single PHP script to:
o accept FORM data for an order with credit card data
o exec gpg on the same server to encrypt the order data and credit card
  [using the public half of the public/private key-pair]
o e-mail the resulting encrypted data to a PC client
o disconnect the PC from the 'net and use Windoze gpg locally to decrypt order
  [using the private half of the public/private key-pair]
o print/file the resulting order and/or
o key it in by hand through your existing credit card acceptance system and/or
o feed it to your dog.  Whatever your existing procedure in place is

This will require some security education and training on the PC client
end, but that's in the realm of the workable.  It's also not unimaginable
that somebody knowledgable about e-mail security, pgp encryption, and
credit card POS terminals and/or a small business's ordering software could
automate the last few steps.  I ain't likely to ever need/do it, but...

If I'm understanding the security issues involved, this is on the same
order of security as CyberCash et al.  Comments and negations from
knowledgable people *MOST* welcome!

NOTE:  If secure access (IE, CONSOLE input or SSH) to the web-server is
available, a private key could be exported/imported to "increase" security.
This would also entail putting the password to the private key in a PHP
script (or other cgi or binary) and keeping that script/binary in a secure
area.  This hardly seems worth the effort to me, since almost anybody could
spoof the FORM inputs into making a fake order anyway.  All I'm really
going for is making sure the credit card data is not transmitted in the
clear.  Comments?

Things I did to make it work.  Not sure what the minimum requirements are
here.  I'm just so excited it actually worked that I'm posting before I
narrow down the critical element[s].

#1.  Use suexec (www.apache.org) to change cgi uid to my shell login.

#2.  Move my keyring to my cgi/.gnupg directory, and a symbolic link in my
home/.gnupg directory to it so gpg will be happy from the shell, but PHP
will know it's okay to read the keys.

#3.  Make keyrings publicly readable/executable.  [Almost for sure not needed.]

#4.  Use putenv (not called setenv, and takes 1 argument!?!) to set my HOME
envrionment variable to /path/to/cgi-bin/.gnupg so PGP could find the
keyring files.  I actually also did putenv("~=/path/to/cgi-bin/.gnupg"),
because I am a Unix moron, and didn't trust the machine to do ~ -> HOME
automagically.  Call me paranoid.

I will play around with these settings some, and see if, as I suspect, the
biggest one is setting HOME, followed by having the right login name/uid
via suexec if you expect gpg to trust that you should be able to send
encrypted messages from yourself.  I suspect that with a public key, it
would be smart enough (thanks to Werner) to "do the right thing", but with
a private key, you pretty much have to be logged in as you to use it.  This
is based on my current very shaky understanding of gpg in the first place.
:-)

Actually, it would be kinda hard for me to test turning off suexec, since I
have to bug my ISP to do it for me. :-(  Volunteers from those of you
blessed with your very own machines, once I eliminate all the other
variables?

I will be making publically available my code (ok, so it will probably boil
down to three lines of code) and more detailed notes and comments from a
Unix/GPG idiot once I work out what's important here.  Any donations will
be cheerfully accepted and cash will be split equally between PHP, GPG, and
me.  I'm keeping the postcards, beer, and any other non-cash donations. :-)

THANK YOU!!!

-- "TANSTAAFL" Rich lynch at cognitivearts.com     webmaster@  and www. all of:
R&B/jazz/blues/rock - jademaze.com        music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com     sculptures - olivierledoux.com
my own nascent company - l-i-e.com     cool coffeehouse - uncommonground.com