Overview
Secure data exchange between third parties for Internet products presents certain significant security-related challenges. Data must be kept confidential, proper authentication mechanisms must provide non-repudiation, and integrity checks must ensure the data has been unaltered in transit.
Unfortunately, there currently exists no widely accepted universal standard for secure data exchange across the Internet between third parties. There are several emerging standards all competing to be the definitive standard. However, these are in their infancy, far from universal acceptance, and with high costs of entry. In the face of this reality, each firm has attempted to develop their own solutions according to their own requirements. CU*Answers has examined many proposed implementations, but none met all of our strict security requirements.
To solve this problem, CU*Answers contracted with a security expert from the National Security Administration (NSA) to architect a secure data exchange solution using the universally accepted and FIPS-approved Triple DES (Data Encryption Standard) encryption algorithm. The result is an encryption engine that:
- Securely encrypts all data sent to CU*Answers. Even if the SSL session is compromised, the data itself is encrypted and thus unusable to an attacker
- Encrypts the URL to prevent “over the shoulder” attacks against the member, as well as URL “hacking” of the session variables in order to compromise a session
- Guarantees requestor’s identity via shared private keys. Requests sent to CU*Answers check imaging servers without being encrypted with the correct key will be ignored. This prevents spoofing or “man-in-the-middle” attacks.
- Data integrity: if data is altered in transit, it will not decrypt properly and the request will be ignored.
- Was independently developed by a security expert from the NSA using industry standard and proven encryption algorithms
Data Exchange Process
CU*Answers’ secure data exchange architecture uses a combination of the Triple DES Crypto API, enforced 128-bit SSL, time-limited tokens, and well-formed and specific requests. This mature solution set has been in use on CU*Answers’ network for nearly two years, in a variety of roles, without incident. See Figure One for a diagram of the complete process:
Triple DES Data Encryption
When a request is issued by clicking on a link, the home banking server will access the CU*Answers CU*CheckViewer Crypto API which encrypts the data to be exchanged with industry standard Triple DES (Data Encryption Standard) encryption. Encryption is facilitated by use of previously shared private encryption keys issued by CU*Answers. When CU*Answers receives the request it is decrypted, processed, and returned to the member via enforced 128-bit SSL.
Please see the Check View Specification section of this document for detailed information on integrating the CU*Answers Crypto API into your home banking application.
Well formed and specific requests with input validation
To assist in maintaining data integrity, a number of checks occur when an image request is received at the CU*CheckViewer server. If the supplied credit union ID does not exist, an error is returned to the home banking server. If the date and/or tracer number do not match an image, an error is also returned.
Time-limited tokens
When a member is redirected from the credit union web server to the CU*CheckViewer web server, there is a predetermined time period in which the request must reach the CU*CheckViewer web servers. If the request fails to hit the web server in the predetermined time period, an error is returned. These steps help maintain data confidentiality and are another layer of request authentication.
Enforced 128-bit SSL Encryption
All communication with CU*Answers’ CU*CheckViewer servers must support 128-bit industry standard SSL (Secure Sockets Layer) encryption. This requirement assists with maintaining data confidentiality and integrity. Connection attempts at less than 128-bit cipher strength are refused.
Implementation
The crypto API is a small file (.dll on Windows platforms) that sits on the home banking provider’s web server out of the web root (preferably on a different logical drive). The home banking web application then merely calls the crytpo API .dll and feeds it whatever information is required. The crypto API then encrypts the data with the private key for transmission to CU*Answers. The call is extremely easy to implement – usually no more than three lines of code are necessary. See the API Specification for more details.
Platform Requirements
The CU*Answers CU*CheckViewer Triple DES Crypto API currently supports Windows 2000 and Windows Server 2003 (including SP1) on Intel-based x86 platforms running IIS 5.0 or newer.
Third Party Server Security Considerations
- Member authentication is the responsibility of the credit union home banking provider. The CU*Answers’ CU*CheckViewer system does not authenticate members and CU*Answers does not assume liability for errors in user authentication made by the home banking provider.
- Home banking server security is the responsibility of the provider, not CU*Answers. Care should be taken to ensure the key is stored securely with appropriate permissions, and that unauthorized access is prohibited.
- To improve security, new keys will be issued by CU*Answers on a periodic basis. The time frames will be established with each third party when the online relationship is established.
Getting Started
To get started with your integration, contact the CU*CheckViewer team at 616-285-5711
