|
FrontBase Documentation |
|
|
|
FrontBase Documentation |
|
|
Backtrack: Welcome! 6. Original Documentation |
Updated:
20-Nov-2000
prev — next Table of Contents |
With FrontBase you have several options for protecting your data, as well as protecting communication against eavesdropping and tampering. The protection is obtained by applying encryption of communication and data storage, passwords for authorization, and black/white listing of computers.
Password protection
Two layers of password protection are provided, database password and users passwords.
Database password
If the database password is set, a client must send the database password to the server as part of the connection protocol, if the server cannot verify the password, the client connection is closed down immediately.
User password
Each database user can have a password, the password is verified by the server when a session is created for that user, if the verification fails the session is not created. When a session is successfully created, the SQL92 defined protection takes over.
Password handling in general
Passwords may be of any length,and passwords are never exposed outside the client software, and they are not even in the database. A soon as an application passes password to the FrontBase client software from the application, a oneway function is applied to generate a password digest. The function will throw away parts of the password so it is impossible to deduce the password from the digest. The user name is part of the digest, so two users with the same password will not have the same digest. The password digest is used for verification instead of the password.
Encryption
Encryption is used to protect communication channels and data storage. When you create a FrontBase you may optionally specify that data stored on the disk should be encrypted, and optionally specify that communication channels between the server and its clients must be secure. You must provide an encryption key for each option specified.
Encryption of data
Data stored on the disk is encrypted using a triple DES in cipher block chaining mode on 512 byte blocks, the data store is block oriented with 512 bytes/block. The initialization vector depends on the logical position of the block within the system, thus blocks with the same contents will never generate different cipher text blocks.
The key used for encryption of data is a 64 bits initialization vector, and 3x56 bits for the DES encryption.
Secure channels
A client and the the server is able to establish a secure channel.. When a client connects to the server, it receives a public RSA key from the server, the client generates a set of random session keys, one for outgoing data and one for incoming data, encrypts those with the public RSA key, and sends the result to the server. The server decrypts the result from the client with use of its private key, and thus the client and the server.have established a common set of secret keys.
The algorithm used for encryption of communication data is a triple DES in byte stream mode with cipher text and clear text feed back. The clear text feedback ensures that an error will propagate to all bytes following the error, which makes detection of errors simple, introduces a small amount of redundancy and uses that for verification in the receiving end.
Tools and Options
A few tools are provided to support key management, and FrontBase has a number of options related to security.
FBKeyGenerator
The key generator is used to generate a set of keys that can be used by FrontBase:
FBKeyGenerator <RSA-key-bit-size> [<key-filename>]
The key-bit-size must be between 1024 and 4096 bits. If the key-filename is specified a the keys are written to that file, otherwise the keys are written to standard output. Each key set is assigned an identification.
Example key text:
FrontBase Key Generator Tue Dec 1 12:22:45 1998 Key ident: fc0c719d DES disk keys: iv(008):9f68d3d1 e25fb047 k1(008):a2dc2f97 7a1a9b5b k2(008):f29ba4e0 346bea31 k3(008):16bf92f4 311cc834 RSA private key: n(128):c7763cbb 9627ff8e 756173f8 2507257c 3b4c349f 0401cc49 8473dff6 9d61752c 020ba963 bd726d91 af249fd0 3b099e3a 543b701c aa26be06 48f7b277 3071db45 9607b9d5 69d2012b 6cc93b62 0536ef69 41b815ce 265e8933 df5ab416 916ee017 a23fe996 99212754 d1168f98 8ba78144 d92bb918 4e5c5c2b d140d79d 602e86ed e(003):010001 d(128):a61baf84 410e5a63 1719eb6c 31d9fbbb b3de48cc 4c97fabb 16d53124 bdf8158e 6abdaf79 62a1d2e1 ca4be3d3 93f6f490 7ae96cfa 5231257b 32752568 e12d507e eed424dd dd3e377a a41f8aeb f7158cf7 e5388bf3 adfd2b1a 62bf2377 a1a49809 1d9c79f8 c4d1a25f 26b464da ddbd8e7a cbb01ca5 847746c2 008821a0 84d93d79 p(064):f8a87b44 77c89ba2 9a70a505 a2618d8c 8814e4d1 e14a920d 868947b0 c10a0542 9477cf9f 7c46e6ed 7c094b8c 85a7f866 81b021c7 06eaa4d5 80c31473 27476b6f q(064):cd59e60b dfdd7d65 5825ba48 86bcb5b6 7a469109 81bdcb91 4381aa21 83bfe3e5 4db26077 b2001209 e916547a 084dcf2b 299ae74d 5f0fe010 535a1376 bdce3563 dmp1(064):f45a0c98 61e59f1b 910cf4fd ae6e92fc f09527af 1fe779d3 14cc3ec8 f149f995 4df4d6f0 f0dd73fd 1810c24f 1ae0cf77 5c264b6b 1bdee590 717242dc 4e531ebd dmq1(064):2e77bf54 c48dac48 788fe0fd 746fd376 bd68a67d 4e3c928a 068a9ae3 069b2f88 bdf2355e 208b5f89 9a9310fe a44e6728 cf3b5c47 e7d101d4 efe79c2b ec7b731d iqmp(064):8fe8b77c 53069c4d 020c2b98 c8fedf59 5381e3a6 8d437b03 f2950da7 c7d6927b ef7b2ea1 e2f17add c5717232 f83bbdcd fa373d94 5fc066f3 4453df6d c1250d7aFBKeyGenerator
FrontBase has three security options:
-scommIf one or both of the -sdisk or -scomm is specified the server requires a set of keys in order to operate. If -keys=
If present the communication between the server and its clients is secure.
-sdisk
If present data stored on the disk is encrypted
-keys=<file-name>
The keys are read from the named file.
is specified the keys are read from that file, otherwise they are read from standard input. When the server is started it checks that the correct and required keys that have been specified.
FBChangeKey
The FBChangeKey tool can be used to encrypt a database that was not previously encrypted, to change the keys used for encryptiion, or decrypt an encrypted database.
FBChangeKey <database-file> [<keys-filename>]If theis not provided the keys are read from standard input. If you provide one key, the database is encrypted if it was not, and decrypted if it was encrypted. If you provide two keys the database is decrypted by the old key, and encrypted with the new. Two keys is simply created by appending the text for the two keys. The tool checks the identity of the keys, so the order in which you append key texts is not significant.
IP Address checks
When a client connects to the FrontBase server, the IP address of the client is checked against a black and white list. If the IP is blacklisted the connection is refused, if the IP is white listed the connection is accepted. The list is arranged such that it will work both as a white list and as a black list. If an IP is white listed you can specify if you require a secure communication channel to that IP. In most cases it will be ok to allow local connections to run without encryption.
A related option is the -localonly option, which makes sure that the Frontbase only allows connections from clients running on the same host as the FrontBase server.
If you have feedback or questions on this document, please send e-mail to doc-feedback@frontbase.com. Please reference the section number and topic. Thanks!!
©2000 FrontBase, Inc. All rights reserved.