Product Documentation

    Since SKFS uses the Linux operating system, all security settings indicated below pertain to the Linux operating system. A site may supplement the standard Linux capabilities with third-party security tools, if their security policy requires it.

    Sites are responsible for ensuring that the addition of third-party tools to SKFS do not violate the security settings created during system setup. Any reduction in SKFS operating system security can create potential vulnerabilities which void StrongKey's warranty on the appliance.

    The Linux firewall, iptables, is configured to only make port 22 (for Secure Shell (SSH)) and port 8181 (for the SKFS EncryptionService) accessible over the network using the Transport Layer Security (TLS) protocol. System Administrators require the use of port 22 for administering the machine remotely, while applications will access the SKFS web service over port 8181. Additionally, ports 7001, 7002, and 7003 are opened selectively between SKFS nodes to enable database replication. Clients outside the SKFS cluster will not be able to access these ports. All other ports, including the Internet Control Message Protocol (ICMP), are blocked from the machine. The denial of ICMP traffic implies that the SKFS server cannot even be pinged on the network. Network Administrators will need to determine if port 8181 is accessible to check for network connectivity to the appliance.

    The SKFS installation process creates some application accounts, but locks all accounts not necessary for the administration of the appliance. This minimizes user access to the Linux operating system from the console or remotely over SSH to just two administrative accounts—root and strongkey.

    Please consult Linux documentation for how to enhance the security of your appliance above and beyond what is provided in the base installation.

     

    Network

    Since the only two ports that are publicly visible on the network are port 22 (SSH) and 8181 (SKFS EncryptionService), all data traversing the network to these two ports are protected from attacks on the wire. SSH encrypts data with a randomly generated session key, while SKFS uses Transport Layer Security (TLS) 1.2, which also protects data with a randomly generated session key. Both applications use public-key cryptography to protect the session keys on the network.

    The SKFS SSH key pair is generated during the installation of the Linux operating system, and its keys are protected using operating system controls. The TLS key pair and digital certificate for the SKFS service are generated during the installation of the Java Enterprise Edition (JEE) application server and are protected using operating system controls and a password.

     

    Relational Database

    SKFS uses a standard relational database management system (RDBMS) to store data about encrypted objects and decryption requests.

    The database service is accessible only from the local machine. Remote clients and applications will be unable to access the database directly because of the firewall controls on the operating system. This does not prevent the SKFS application from accessing the database locally.

    While there are no special requirements for database security (other than what may be required of a site's security policy for Production databases), it is recommended that backups of the database are stored separately from standard backups in the event that vulnerabilities in the encryption algorithm are discovered in the future. Controlled access to database backups will minimize any damage from such potential discoveries.

     

    JEE Application Server

    SKFS uses a standard JEE application server to process web service requests. While the application server hosts the application, nothing in the configuration of the application server allows someone to gain access to sensitive data in the database.

     

    Lightweight Directory Access Protocol (LDAP)

    SKFS is capable of integrating with LDAP on the network to authenticate and determine the authorization of users who request its web services. The LDAP service may either be an industry standard LDAP service or Microsoft Active Directory.

    When a user requests a register or authenticate web service from SKFS, they must pass to the web service an LDAP username and password with the data. The SKFSServlet uses this username and password to authenticate to the LDAP service and then determines whether the user is a member of one of two LDAP groups—the FIDORegAuthorized or FIDOSignAuthorized groups—based on the type of service requested by the user. Only when the two LDAP checks pass does SKFS continue with the performance of the service.

    If the LDAP service is not protected on the network using either TLS or Internet Protocol Security (IPSec), there is a possibility that attackers may snoop the LDAP credentials between the SKFS server and the LDAP server. The compromise of these credentials will allow attackers to legitimately request cryptographic web services from the SKFS server using the compromised credentials.

    It is strongly recommended that sites either use the LDAP over TLS capability, or tunnel the LDAP service over IPSec. In either case, the encryption on the wire will protect the user credentials being sent to the LDAP service for authentication.