PrivateServer Knowledgebase

When creating the STARTUP and INIT cards using the PSVGenCards.exe utility you should write down (and keep in a safe) the two parts of the SVMK (one part is requested when creating the INIT card, and the other part when creating the STARTUP card).  This will create a new set of STARTUP and INIT cards that will be used for initializing and restoring a backup for a different PrivateServer in case of a damaged server and/or loss of the original cards.

Note: When generating the INIT and STARTUP cards using a PrivateServer client version 4.0 and up, you can generate a backup for them. Please note that the SVMK of the server that created the backup file must be identical to the SVMK of the target PrivateServer. The name of the target PrivateServer should be the same as the name of the original PrivateServer. You must have the original root card to certify; otherwise, the restoration process will fail. In order to create the cards you need to run the utility PSVGenCards and do the following:

• You can skip the Root card creation if you already have one.
• In the INIT section it is important to enter the exact SVMK part that was entered when creating the original INIT card. 
• In the STARTUP section it is important to enter the exact SVMK part that was entered when creating the original cards. 
• Enter the details of a user who will be permitted to connect to the server without a card following the initialization process.

When generating cards to be used as INIT or STARTUP in PrivateServer version 3.x, MCOS cards must be used. In PrivateServer version 4.x all the cards can be PrivateCards.

• MCOS cards –"Gemplus" is written on the smartcard chip. Please note that these cards are EOL (end of life) and are no longer supported.
• PrivateCards - a high security PKI-based smartcard with a 144 KB memory capacity. The card performs all the sensitive functions on the chip itself, providing users with a significantly stronger authentication mechanism.

The MCOS smartcard chip is rounder in shape, unlike the PrivateCard that is square-shaped but has round edges.

When generating cards for users that will connect from the PrivateServer client machine, you may use both types of the cards provided the client machine is using CryptoSafe for the smartcard reader.  If the client machine has PrivateSafe or USB reader, you can only use PrivateCards.

The definitions for secure networks and non-secure networks should be determined by the PrivateServer operator.

• Secure network means that measures have been taken to limit access to the network. For example, a network with cross cable between a client machine and the PrivateServer is considered a secure network.
• Non-secure network means that the network has unlimited access. For example: a PrivateServer that is connected to the internet.

Each user in a PrivateServer database has an access level that determines whether the user must access it from a secured network. If you define that a user must connect from a secured network, then that network must be added or defined in the “Secured Networks” option in the PrivateServer console.

PrivateServer has 2 NICs; by default, both are defined as ‘secured’. You may define both of them as ‘secured’ or ‘non-secured’.

There are five access types:

• Users may connect from a non-secured network without the need for authentication (in this case, authentication is done by a key that is password protected).
• Users must connect from a secured network, but without the need for authentication.
• Users must connect with authentication from a non-secured network.
• Users must connect with authentication but only from a secured network.
• Users cannot connect to the PrivateServer.

An authenticated session means that the user uses a certain media to connect to the PrivateServer. The media stores the user's authentication private key, and can be a smartcard, a Minikey or a key file.

Note: In a production environment, ARX does not recommend deleting and recreating users. This is because if a key is linked to only one user, then deleting the user will make all keys unusable. It’s preferable to lock access to a user or changing the users’ access level to 5, which prevents the user from connecting.

No, the time of the PrivateServer may not be changed.

No, the time of the PrivateServer may not be changed.

These are general TCP-IP errors, they are not PrivateServer specific. 

• Error 10054 means that an existing connection was forcibly closed by the remote host. 
• Error 10038 means that an operation was attempted on something that is not a socket.

For more information:

Backing up a user is important, as it will enable users to connect to the server should any loss/damage occur to the original media.

When creating a backup user, be sure to use the same authorization mask, the same access level, the same certifier, etc. The certificate lifetime of the backup user should be longer than the certificate lifetime of the original user. This backup user must have the same access rights to keys (owner/user) as the original user. It is highly recommended that important users be backed up.

Backup cards are used if/when the original cards are lost or damaged, or if the original user can no longer connect because his/her certificate has expired.

If the certificate lifetime of the original user expires, the backup user can connect and renew the certificate so that the original user is able to connect. In this case, the backup user will be able to connect to the server and perform all operations that the original user was able to perform.

If you add or grant rights to original keys, you must also do so for backup keys to ensure that they have the same rights.

Keep in mind that the backup user’s certificate will need to be renewed before it expires so that access to PrivateServer is not denied.

1. Check from another client station if the log file appears there. 
2. Try to retrieve the log file via MNG and open it with a different viewer (not Notepad).
3. Check that you have enough hard disk space. 
4. Check the PrivateServer's console when trying to retrieve the log, by viewing the PrivateServer console. If the counter numbers are increasing, this means that a log file is being sent to the client.

Sometimes, the CryptoSafe reader doesn't work with PrivateCards but only with MCOS smartcards, or you may get some sort of error or inconsistent behavior from the reader. In most cases these problems are solved by reloading the CryptoSafe's DLMs.

To reload the CryptoSafe’s DLMs:

1. Reload the DLM's with the Screset.bat utility.
2. Verify that they are indeed loaded (Step 1).
3. If they have not loaded successfully, try replacing the CryptoSafe reader.

• A key user may only perform cryptographic operations with the key (i.e. encrypt, decrypt, sign, verify, etc.).
• A key owner may obtain the key's value (as long as it's not read-locked). A key owner can delete the key and modify sensitive attributes of the key, and also define other users or owners for the key.

The error may be caused if you are using a STARTUP card which is from a different pair than the INIT card.

Starting with PrivateServer version 4.2 and later, the method in which the SVMK is calculated was changed due to FIPS demands, so that only the same set of cards will provide a valid SVMK.

If you have two sets of cards (set A and set B), set A INIT + set A STARTUP, the resulting SVMK will be equal to set B INIT + set B STARTUP’s SVMK. However, it will not be equal to set A INIT + set B STARTUP, nor will it be equal to set B INIT + set A STARTUP (each such mix will give you a completely different SVMK).

This reader must be set manually. Please add the following registry entry to the workstation and reboot.

[HKEY_CURRENT_USER\Software\ARL\ARCryptoKit\Manager]
"PCSCREaderName"="SCM Microsystems Inc. SCR33x USB Smart Card Reader 0"

If your organization has a security protocol of handling smartcards, use it. In case you don’t have a protocol, or want to review it, please read the following guidelines.

For an implementation of the PrivateServer environment, you need the following four smartcards: Root, INIT, STARTUP and First.

It is always suggested to create at least one backup copy of the INIT and STARTUP pair, (two backup pairs are preferred).

Make sure that during the creation of the smartcards you write down the PrivateServer ID and PrivateServer name, and both of the SVMK parts.

After the environment is set, make sure you make another strong administrative user (i.e. a user with full access rights/authorizations) such as “second”, “admin” etc., which is certified by Root or First. Then, backup the database with the added user.

The Root card is unique and cannot be replicated or replaced by any other card.

If you store the smartcards and their passwords in separate places (for example: root and INIT in safety deposit box A; First and passwords in safety deposit box B; STARTUP cards inside the PrivateServer for unattended startup sequence, and the backup pair of INIT STARTUP with their passwords in safety deposit box C), then make sure that you create a list of all the smartcards with their whereabouts, replicate this list as needed, and set it in each site where the smartcards are stored, so that when you need a specific smartcard or password, you will know where to look.

• To start the PrivateServer or to change the IP address: STARTUP card and STARTUP password.
• Initializing a new environment: INIT card and INIT password, STARTUP card and STARTUP password. If restoring existing backup after the initialization: First card and First password. 
• Reset tampering: INIT card and INIT password, STARTUP card and STARTUP password.
• Restoring backup on existing environment: First card and First password or any other administrative media and password.
• Creating a new user media: Empty media, Root card and root password (to certify the new media), First card + password (to create user reference inside the PrivateServer), or only First card and password (to create user reference and certify the media).
• Recreating another pair of INIT/STARTUP cards: Pair of empty smartcards, Root card and root password (to certify the new media), PrivateServer name and ID, Both parts of the original SVMK or working pair of existing INIT/STARTUP + passwords.

There are three ways to convert old PrivateServer version 3 smartcards to a PrivateServer version 4 compatible pair. The conversion is performed on INIT and STARTUP cards only. The conversion is performed by PSVGENCARDS.exe v4.6.2 and up.

• Conversion of the same pair. In this case, we simply read the INIT+ STARTUP data. The application converts the data in the memory and then writes it again on the same INIT + STARTUP smartcards.
• Pros: This is the quickest way, and requires no added materials except the original INIT+STARTUP cards and their passwords. This is recommended in test or temporal environments.
• Cons: This is an intrusive operation, if these are the only existing production cards, it is recommended not to use them, as there is always a concern that an occasional power failure / smartcard disconnection during writing to the cards can damage them.
• Conversion from existing pair to new generated pair. In this case, we are only reading the data from the original cards; the application converts the data and writes it on a new pre-created pair.
  The new pre-created pair must have the same PrivateServer ID and PrivateServer name, and must be certified by the original root.
• Pros: This is a less intrusive operation as there is no writing on the original cards.
• Cons: There is still some concern regarding the existing set as you still have to insert them into reader. This is also the longer operation, requiring the original root smartcard, its password, and two pre-defined smartcards with original PrivateServer ID and PrivateServer name, and must be certified by the original root.
• Creation of new cards based on the original SVMK pairs. In this case, you simply re-create the original smartcards on new PrivateServer version 4 media type using all the original data. You must have both parts of the SVMK in the correct order, the PrivateServer ID + PrivateServer name, the original root and its password.
  Note: If the SVMK parts stored do not fit the SVMK on the PrivateServer, the environment will not run.
• Pros: This is a completely safe and non-intrusive method which does not involve the original smartcards.
• Cons: This method is time consuming and requires two additional smartcards and SVMK parts and additional data. Furthermore, if the SVMK parts do not match the PrivateServer SVMK, the cards will not work.