http://mivo.truxoft.com
MIVO!
miva beyond limits

MIVA^®  SECURITY:  Miva and PGP/GPG

by Ivo Truxa, 03/13/2001  changelog

1. What Is PGP?
2. What Is GPG?
3. MvPGP function library
4. Download the library / View the code
5. MvPGP Installation
6. Calling examples
7. Compatibility
8. FAQ
9. Troubleshooting
10. Security notes
11. Useful links
12. User Comments

top

From The comp.security.pgp FAQ:

PGP is a program that gives your electronic mail something that it otherwise doesn't have: Privacy. It does this by encrypting your mail so that nobody but the intended person can read it. When encrypted, the message looks like a meaningless jumble of random characters. PGP has proven itself quite capable of resisting even the most sophisticated forms of analysis aimed at reading the encrypted text.

top

GPG or GnuPG stands for GNU Privacy Guard

From the the GnuPG Homesite:

top

MvPGP library contains a self-installing script, MvPGP parameter viewer, testing form, and a set of functions building an interface between Miva applications and PGP or GPG programs.

When run for the first time, MvPGP library attempts to find the GnuPG or PGP binary, your private cgi-bin and the Miva data directory. If it does not succeed, it asks you to enter the paths manually. MvPGP was developed and tested with PGP 2.6.2 (an old but free version) and with GnuPG 1.0.4. It should work with newer versions as well.

Most usually, you will have a PGP freeware 6.x or 7.x on the client side. There is also GnuPG for DOS/Windows, but as for now it has just a command line interface in contrary to PGP that integrates nicely with common e-mail clients. GnuPG is an Open Source application, with much more relaxed license then PGP and I suppose that in long term it may get much more popular then recently. Both applications can work fine together, but if you are using older versions of PGP, you may need some effort to find key types that are accepted by both (for copyright reasons there are some algorithms that are not available by default in GnuPG and older versions of PGP do not use some modern algorithms used in GnuPG). I'll try to bring here work-arounds for most common problems as soon as I find some time for it.

Please keep on mind that you should never use the same secret private keyrings and same pass phrases on your remote server as you use for yourself! For encrypting text and sending PGP e-mail you do not need any private key and in fact, for security reasons, you may remove it from your server. You only need a public key for each of the target users (recipients). Please visit PGP oriented web sites and news groups to get more information on PGP, GnuPGP, OpenPGP, cryptography and security.

top

Please use the non-coloured plain-text source code for copying. The coloured syntax is easier to look at, but may contain minor mistakes. PGP should verify the B&W code signed by myself. Call the file mvpgp.mv (or something else if you wish)

The MvPGP library is free for personal non-commercial use. I offer the program without any warranty. Please use on your own risk only. Please keep all credits and comments. All rights reserved.

If you are interested to use MvPGP library in scripts that you are writing for customers or re-selling them or if you plan to resell it standalone or together with other modules, libraries or scripts or to make profit with it in any other way, please let me know.

top

Before installing the MvPGP library, be sure to have properly installed PGP or GnuPG on your server. After creating your key pair, import public keys of all potential recipients. Most probably you want to send encrypted e-mail to yourself too. On your local system, export your public key, upload it to your server and import it into your keyring. Again: do not use your own keyrings or pass phrases on the remote machine! In the same way you can add other recipients.

Succesfull installation of MvPGP requires:

• Miva Empresa on a Unix system
• Installed and working PGP or GnuPG on your server
• Private cgi-bin directory accessible and writable by Miva
• Working shell accesible by Miva
• Keyring in the PGP/GnuPG home directory containing recipients' public keys

Please read also the FAQ on the MmPGP (Miva Merchant PGP e-mail notification module)

After testing the functionality of PGP or GPG, just place the MvPGP library somewhere in your Miva script directory, run it from a browser and follow the instructions. MvPGP attempts to create two files:

1. /mvpgp/mvpgp.conf in your Miva data directory, containing MvPGP settings. You may need to edit the file manually if the automated installation did not set up the right parameters.
2. /cgi-bin/mvpgp.cgi in your private cgi-bin directory. It is a shell script used as an interface between Miva and PGP or GnuPG.

top

Sending encrypted e-mail: the text may be a string or a variable containing multiple lines. Please note, that the e-mail address must be present in your public keyring on the server. Check the PGP/GnuPG documentation to see how to add new public keys to your keyring.
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpSend('friend@some.com','Text to encrypt')}">
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpSend(g.email,g.LongText)}">


The same function accepts also filenames. If the second argument of the function is an existing filename in your Miva Data directory, it will be encrypted and sent by e-mail to the address (if present in the keyring).
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpSend(g.email,'/Merchant/install.log')}">


pgpEncrypt() function returns encrypted text or the content of a file passed in the 3rd argument. Public key of the target user (2nd argument) is used for the encryption. The first argument determines if the output comes with or without a PGP header.
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpEncrypt(1,'friend@some.com','Text to encrypt')}">
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpEncrypt(0,g.email,'/Merchant/install.log')}">


pgpListKeys() function returns a list of e-mail addresses extracted from public keys present in your keyring. If the first argument is empty or 0, pgpListKeys returns a pipe delimited list. If the argument is non-empty, the function returns OPTION list for a SELECT form element (drop-down box), containing the available recipients' addresses. If the argument is equal to one of these addresses, the appropriate option is selected.
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpListKeys('')}">
<MvDO FILE="mvpgp.mv" NAME="ret" VALUE="{pgpListKeys('friend@some.com')}">


Please review the code of the test form inside of the MvPGP library to see practical examples of use of the mentioned functions. I will add more functions for decrypting, managing key rings and other as time allows.

top

MvPGP was succesfully tested with PGP 2.6.2, PGP 5.0 (new in MvPGP version 0.075) and GnuPG v1.0.4. Miva Empresa 3.78 was used, and for security reasons I strongly recommend to use the latest Miva version. There are serious security flaws in all prior versions!

top

What is PGP and GPG?

Encryption programs. See more at the  art0038.htm

What is ~/ ?

In Unix ~/ stands for the user home directory. It means the directory where all your files are located - it may contain folders keeping your web documents, miva data directory and many other files. Usually and correctly it should not be accessible from the web by a browser. Typically, on many systems it is equivalent to /home/yourloginname/

How to initialize an already installed PGP or GnuPG?

Please refer to the PGP/GPG vendor's documentation for details. Often the following two steps would be enough to initialize a properly installed PGP or GnuPG if MvPGP/MmPGP is unable to do it for you:

1. Create a .pgp (for PGP) or .gnupg (for GNU Privacy Guard) directory in the server home directory (typically /home/username/.pgp or /home/username/.gnupg)
2. Generate a secret keypair - in a Telnet session type:
   pgp -kg (PGP), resp.
   gpg --gen-key (GnuPG) and follow the prompts.

How do I import my public keys into the server's key ring?

Preferably use the MvPGP/MmPGP interface for doing so. You can do it from the shell too:

1. On your local machine export your public key (not the private one!) to a file.
2. Upload the file to your ~/.pgp (resp. the ~/.gnupg) directory on the server.
3. Type pgp -ka "the key file name" (PGP),
   resp. gpg --import "the key file name" (GnuPG)
4. Type pgp -ks "key's e-mail address" (PGP),
   resp. gpg --sign-key "key's e-mail address" (GnuPG) to sign the imported key.

Why the imported keys do not appear in MvPGP/MmPGP?

See also the troubleshoting section below. There are several possible reasons:

• If you successfully imported the key manually in a shell session (Telnet or SSH), then, most probably, your server uses other user ID (and therefore also other PGP/GPG configuration and keyrings) for cgi scripts than your own uid used in a shell sessions.
• If you attemped to import a key with the MvPGP/MmPGP interface, then the PGP home directory is not properly set. It must be either inside of the original user home directory of the uid used by the web server when calling cgi scripts or it must be a subdirectory of the mvpgp (resp. mmpgp) directory in your own Miva data directory.
• The key was not a valid public key or is not compatible with the PGP/GnuPG version on your server. Check also the paragraph "Unsupported packet format..." below.
• You imported the key from a public server, but it was down, or you did not use the 8 bytes long hexadecimal user ID from the key's properties

Why I am getting: "gpg: Warning: using insecure memory!" (GnuPGP)?

It means that GPG uses a portion of operating memory possibly vulnerable against attacks from people having access to the machine (not visitors from the web). Although it is not a too serious threat, you or your system administrator should change the GPG binary permissions as follows: chmod +s /usr/local/bin/gnupg

Why I am getting: "Unsupported packet format - you need a newer version of PGP for this file" (PGP 2.6.x)?

On your local PC (with the target keys), create and export a key with RSA Legacy algorithm (resp. RSA if no RSA Legacy available) instead of DH/DSS.

top

'Cgi-bin directory not found!' (MER-PGP-00008)

During the installation process, MvPGP/MmPGP needs to be able to create scripts in the currently active cgi-bin directory. It means that this directory must be accessible from either the Mva Script or the Miva Data directory root. If the installtion routine does not find the paths to the cgi-bin automatically, you need to enter the path, relative to either the Miva Data or the Miva Script directory, manually.

It does not make any sense to create a new cgi-bin directory (otherwise MvPGP/MmPGP would create it itself, of course). Only that cgi-bin directory that is assigned as ScriptAlias in the Apache configuration file (or equivalent on other web servers), may be used.

If the cgi-bin is parallel to both Miva Data and Miva Script directories (and nowhere overlapping with any of them), there are still other possibilities to install MvPGP/MmPGP. Try one or more of the following instructions:

1. Create a symbolic link manually within your Miva Data or Script directory, linked to the original cgi-bin. In the same time, you have to change the Miva configuration to accept symbolic links (securityoption=15 - disabled by default). After completing the installation you should remove the symbolic link and reset the Miva configuration to the original state, so everything would be as safe as before again.
2. Temporarily change the ScriptAlias directive for your domain in the httpd.conf to point to a temporary cgi-bin directory within your Miva Script directory. After completing the installation sucesfully, copy the mvpgp.cgi (resp. the mmpgp.cgi) to the original cgi-bin directory, reset the httpd.conf to the orginal state and remove the temporary cgi-bin.
3. If you are using GnuPG on the server side, you may download the mvpgp.cgi shell script and install it in your cgi-bin. Set its permissions to 755 and run the mvpgp.mv installation directly from your browser in this way: http://yourdomain.com/mvpgp/mvpgp.mv?MVP_Cybrhost=1

'Miva Data Directory not found!'

One of possible reasons of this error message is a different user ID (uid) used for the Miva engine (usually the account owner's uid) and another one for the web server (often 'nobody' or 'www' with Apache without cgi wrapper like suexec). Another reason may be use of other than the default name for your Miva Data directory. The most secure way, is entering the full (absolute) path to your Miva Data directory. If you are unsure about the correct path, log in with Telnet, go to your Miva Data directory (e.g. 'cd htsdata' or 'cd mivadata'; on some systems the Mivadata may be identical with the user root dir) and type pwd to see the full path. Here are few examples:
/home/accountName/htsdata/   (e.g. at CI Host)
/home/sites/site156/mivadata/   (e.g. at Cybrmall)

'No public keys!'

Most evident reason is that you have not imported any target public keys into your key ring. If you did it already (whether manually in Telnet/SSH or through the MvPGP/MmPGP interface), then a different user ID (uid) for CGI scripts and for Miva scripts could be the reason. Web servers (like Apache) sometimes use a special uid for calling documents and CGI scripts - often 'nobody' or 'www'. When there are respective user directories (e.g. /home/nobody), MvPGP/MmPGP should be able to work with the default '~/.gnupg' (resp. '~/.pgp'), but if there is no such directory on the system, you have to enter it manually. If the default dir does not work, a directory within the MvPGP/MmPGP subdirectory in the Miva Data dir should be used (see the paragraph above for ways to find out the path on your system):
/home/accountName/htsdata/mvpgp/.pgp/   (e.g. at CI Host)
/home/sites/site156/mivadata/mvpgp/.pgp/   (e.g. at Cybrmall)
(replace the mvpgp with mmpgp when installing a Merchant PGP module instead of the plain MvPGP library)

Enter the new location for the PGP/GPG home directory and try to import a key through the MvPGP/MmPGP interface. NOTE: MvPGP/MmPGP always tries to create the directory with the web server's uid and you may not be able to delete it from within a Telnet/SSH session, unless you have root access to the server. The directory may be removed with a cgi script in your cgi-bin called from a browser:

#!/bin/sh
echo "Content-Type: text/plain"
echo ""
rm -Rf /home/sites/site156/mivadata/mvpgp/.pgp/
exit 0

top

When using the MvPGP library or the MmPGP module, you should be aware of certain facts regarding the security.

You should disable access to the mvpgp.mv script to avoid access to it by by unauthorized visitors. Normally it is enough to disable both, the configuration listing and the test with selecting the 'hide' checkboxes on the mvpgp.mv page. You may additionally restrict the access to the file from the web totally in the Apache's .htaccess configuration file in this way:

<Files "mvpgp.mv">
 Order Deny,Allow
 Deny from all
</Files>

Because of the location of the PGP/GnuPG configuration and key ring files on a public server, you should not trust the encrypted e-mail comming from the server. Anybody being able to break into your server, would be able to send e-mail using your PGP/GPG configuration and your secret keys. MvPGP/MmPGP in the recent version does not install any secret keys and if you do it manually, you should never use the same passphrases as you use for your usual encryption. Keep on mind that if somebody gained access to your private keys on the server, theoretically he might be able do crack then using brute force. There is no risk, if the secret key is used just on that server and never used for signing or exporting trusts to other keys. MvPGP/MmPGP does not use the secrete keys at all, so you may remove them from the keyring, or use just a dummy secret keys. MvPGP/MmPGP encrypts messages with the addressee's public keys only and do not sign them with the server's secret key.

MvPGP/MmPGP on systems with GnuPG uses the option --always-trust for any imported keys. This was made to simplify the automated installation procedure, but if you prefer signing all imported keys manually, please edit the mvpgp.cgi (resp. the mmpgp.cgi) in your cgi-bin directory and remove any instance of the --always-trust option. It brings you more security, because every new key must be then signed using the server's passphrase manually from the shell (SSH/Telnet).

top

top

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2008