DEI software uses a variety of methods to control access to your data within your systems and while it is in transit. This article provides an overview of the security features of DEI software, including the features of specific products.
Each MTP/IP datagram includes a 32-bit transaction identifier whose sole purpose is to identify incoming datagrams. This is in addition to separate session, sequencing, and flow control identifiers. By using a dedicated transaction identifier, MTP/IP makes it very difficult for an attacker to successfully inject data into an ongoing transaction. TCP/IP, by contrast, uses only a sequence number for validation, which makes it more vulnerable to injection attacks.
The MTP/IP Core Software Development Kit supports packet level just-in-time encryption and decryption. This allows applications complete freedom to choose their encryption algorithms and keys while ensuring high performance and minimal integration effort.
MTP/IP guarantees that upon successful completion of a data transport transaction, the data it delivers at the destination will be byte-for-byte identical to the data it was given at the source. Data in transit is protected by multiple checksums, a patented transport state management system, and optional encryption with tamper protection. See Tech Note 0028 for more about data transport integrity.
The ExpeDat and SyncDat applications all offer the Advanced Encryption Standard (AES) algorithm with 128-bit keys. Content encryption may not be enabled by default, so be sure to apply the appropriate option if you desire encryption.
In most WAN environments, encryption creates minimal CPU overhead. But if your network is very fast (such as a gigabit LAN), then enabling encryption may significantly reduce throughput. If you find that encryption is necessary but hurting performance, consider using a packet based hardware Virtual Private Network, such as IPsec. Note that MTP/IP cannot be used with SSL VPNs as they do not support packet level data transport.
The ExpeDat and SyncDat servers can authenticate transactions via usernames and passwords. In most installations these will be passed to the operating system login authentication service, allowing integration with NIS, Active Directory, LDAP, or any other services supported by the OS. The servers also support use of a private authentication database. Passwords stored in the private database can be hashed for on-disk security.
As a convenience, the ExpeDat and SyncDat command line clients can store usernames and passwords in an encrypted database. This allows users to type a password once, and not have to re-enter it for several hours. Database entries can be made permanent to facilitate scripting. The authentication cache can also be disabled for heightened security.
The DropDat client embeds an encrypted password within each droplet.
The ExpeDat and SyncDat servers control file access primarily through the use of operating system access privileges. Users who authenticate with a system username and password will have the same file access permissions as they would if they logged in via a shell. Users who authenticate with the private database can be assigned to existing system user and group ids (for unix systems), and can be assigned additional access restrictions such as being restricted to one directory or being read-only.
Both ExpeDat and SyncDat will attempt to preserve basic file access attributes whenever the client and server operating systems support them. For unix based systems, this includes the file mode, user id, and group id. For Windows, it consists of the Read-Only flag. Access control lists are not explicitly copied, but can be inherited from parent directories.
For additional information about the capabilities of each application, please refer to their product manuals: ExpeDat, SyncDat.