Application Security Overview
SeaCat uses OpenSSL as a cryptographic provider. Thanks to this:
- SeaCat is transparent in the implementation of security measures (OpenSSL source code is publicly available);
- SeaCat provides strong encryption on all - even old - devices (e.g. mobile phones) because of OpenSSL cryptographic library integration.
- SeaCat is immune to most cyber-attacks against platform-specific cryptographic issues;
- SeaCat is transparent in the implementation of security measures;
SeaCat uses such cryptographic configurations that provide the highest possible level of security. SeaCat follows U.S. government computer security standard, FIPS 140-2 which describes Security Requirements for Cryptographic Modules.
SeaCat is also designed to support advanced security requirements such as private keys stored on Near Field Communication devices, SIM cards or secure enclaves, payload encryption and others.
SeaCat’s releases are planned at least once every three months. Emergency releases (e.g. bug or vulnerability is found in OpenSSL library or other components) are available up to 1 day after the fix made public by a third party. TeskaLabs informs customers and helps them upgrade.
More information about OpenSSL releases strategy.
SeaCat Gateway identifies Client by using mutual authentication. Based on Client Certificate, SeaCat Gateway supports two modes of operation: authorized and anonymous.
Authorized SeaCat Gateway is dedicated to authorized Clients (with valid Client Certificate) only. Clients in onboarding state are separated from known and authorized Clients. In general, every single Client Connection is handled by a dedicated system process (child process of the main SeaCat Gateway daemon process) with de-privileged rights without any possibility of elevating rights.
Anonymous SeaCat Gateway is dedicated to new Clients in onboarding state. It is possible to combine authorized and anonymous modes of operation. When it operates in both modes simultaneously, single SeaCat Gateway handles both authorized and onboarding Clients. Those functions are separated for large-scale installations.
Applications has different authentication levels based on their onboarding state:
|State||SeaCat Gateway mode|
|Client Certificate expired/revoked or without Client Certificate||anonymous|
|valid Client Certificate||authorized|
|valid Client Certificate with elevated rights||authorized|
Client Connection Transport Layer Security (TLS)
Client Connection uses Transport Layer Security version 1.2 with these parameters:
Enabled cipher suites sorted by priority:
- ECDHE+aRSA+AES+SHA384 (for iOS native support)
- ECDHE+aRSA+AES+SHA256 (for iOS native support)
No other cipher suites are enabled for security reasons.
The negotiated cipher is ECDHE-RSA-AES256-GCM-SHA384. The last two cipher suites are present to maintain backward compatibility and can be disabled for new deployments.
- Elliptic Curve Diffie–Hellman (ECDH)
- Ephemeral ECDH keys for forward secrecy
- RSA 4096
- AES 256 with GCM
- FIPS 140-2 compliant
Custom cipher configuration (e.g. in a case of RSA is preferred over elliptic curves) is supported via configuration option.
Client Connection Mutual SSL Authentication
For ensuring the security of every Client Connection, mutual SSL authentication is used.
The basis of mutual SSL authentication is a certificate verification on both sides of the Client Connection. This approach ensures confidentiality, integrity, authenticity and non-repudiation of data sent via Client Connection. This approach also uniquely identifies every Client, which effectively protects against Man-In-the-Middle attacks. No other Client except the whitelisted one is authorized to establish Client Connection.