This chapter describes retailer and solution specific responsibilities for ensuring EFTLink is securely implemented and configured.
EFTLink installation defaults to secure values, however these may be overridden if desired (for example changes to crypto-agility).
The following is a list of configuration options which are secure by default, but may be incorrectly configured to insecure settings.
Use of TLS over SSL may be specified using the following setting.
TLSEnabled = true
This specifies that a TLS connection is to be used. If this option is not enabled, then communications between the POS and EFTLink will not be secure and data over this connection can be viewed.
Default setting: true
On the connection between POS and EFTLink the protocol and ciphers used to secure the data can be configured.
Restricting the protocols to TLS 1.2
ProtocolsWhiteList=SSLv2Hello,TLSv1.2
Currently the supported protocols include SSL and TLS1 / TLS1.1 which are disabled by the above setting.
SSL / TLS1 / TLS1.1 are all considered insecure by today's standards, so only TLS1.2 should be permitted.
SSLV2Hello is retained as this is merely a handshake to determine which protocol to use - in this case only TLSv1.2
A large number of ciphers is available on the TLS connection, which may be negotiated automatically.
Restrictions on the ciphers used however is applied in the software.
Both a blacklist and whitelist are utilized to enable certain ciphers and disable others.
The cipher must be present on the whitelist and not present on the blacklist in order to be included in the permitted cipher list.
If the blacklist is not specified, only the whitelist will be checked.
For best security, a combination of whitelist and blacklist is configured by default.
If the cipher is a match for both the blacklist and whitelist, the cipher will be excluded.
A full list of ciphers permitted will be logged at the time a connection is attempted.
#Crypto-Agility - Communications
#Protocols Secure setting
ProtocolsWhiteList=SSLv2Hello,TLSv1.2
#Cipher Secure setting
CipherWhiteList=TLS_DHE_.*_WITH_AES_128_.*,TLS_ECDHE_.*_WITH_AES_128_.*,TLS_ECDH_.*_WITH_AES_128_.*_.*,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA
CipherBlackList=SSL_.*,TLS_EMPTY_.*,.*_SHA,.*_3DES_.*,.*_DES_.*,.*_WITH_NULL_.*,.*_anon_.*_.*,.*EXPORT.*,.*LOW.*,.*MD5.*,.*DES.*,.*RC2.*,.*RC4.*,.*PSK.*
#Crypto-Agility - Communications
#Protocols Secure setting
ProtocolsWhiteList=SSLv2Hello,TLSv1.2
#Protocols Default
#ProtocolsWhiteList=SSLv2Hello,TLSv1.2
#Protocols Java 1.6 setting for backwards compatibility
#ProtocolsWhiteList=SSLv2Hello,TLSv1.2,TLSv1,TLSv1.1
#Cipher Secure setting
CipherWhiteList=TLS_DHE_.*_WITH_AES_128_.*,TLS_ECDHE_.*_WITH_AES_128_.*,TLS_ECDH_.*_WITH_AES_128_.*,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA
CipherBlackList=SSL_.*,TLS_EMPTY_.*,.*_SHA,.*_3DES_.*,.*_DES_.*,.*_WITH_NULL_.*,.*_anon_.*_.*,.*EXPORT.*,.*LOW.*,.*MD5.*,.*DES.*,.*RC2.*,.*RC4.*,.*PSK.*
#Cipher Default
#CipherWhiteList=TLS_DHE_.*_WITH_AES_128_.*,TLS_ECDHE_.*_WITH_AES_128_.*,TLS_ECDH_.*_WITH_AES_128_.*_.*,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA
#CipherBlackList=SSL_.*,TLS_EMPTY_.*,.*_SHA,.*_3DES_.*,.*_DES_.*,.*_WITH_NULL_.*,.*_anon_.*_.*,.*EXPORT.*,.*LOW.*,.*MD5.*,.*DES.*,.*RC2.*,.*RC4.*,.*PSK.*
#Cipher Java 1.6 setting for backwards compatibility
#CipherWhiteList=
#CipherBlackList=SSL_.*
Several of the cores now support crypto agility.
Each core uses a set of parameters in the [corename].properties file.
#############################
# Crypto-agility - keystore #
#############################
#Key Generator (example AES)
crypto.keygenType = AES
#Cipher Type (example AES/CBC/PKCS5Padding)
crypto.cipherType = AES/CBC/PKCS5Padding
#KeySize
crypto.keySize = 128
#No of iterations in keystore
crypto.iterations = 100000
This currently applies to Adyen, Cayan and Ocius Sentinel cores.
Currently shipping with the default settings above. The main improvement over existing default settings are to increase the number of iterations of encryption.
A mechanism has been provided to change the algorithm by running a command from the prompt with parameters including keystore location and encryption properties to use. Full details of crypto-agility commends for each core is included in the Oracle Retail EFTLink Core Configuration guide.
Each individual core may also have specific security requirements. These are detailed here:
A password for Adyen is entered using the supplied configuration batch file.
The encrypted password is then stored in the adyen.properties file.
The AJB core may be configured to enable signature logging via the property
enable.signature.logging
By default this is set to False. This should not be set to TRUE in a secure environment, as this will expose PII information - the customer signature.
The cayan communication may be secured by employing an https connection over a secure socket.
This is done through the cayan.properties file:
#secure port
ced.port = 8443
Performing all Actions on the Pin Entry device over https is the default secure option:
http.action.add_item = https://cedIp:cedPort/v1/pos?Action=AddItem
http.action.del_item = https://cedIp:cedPort/v1/pos?Action=DeleteItem
http.action.del_items = https://cedIp:cedPort/v1/pos?Action=DeleteAllItems
http.action.start_order = https://cedIp:cedPort/v1/pos?Action=StartOrder
http.action.end_order = https://cedIp:cedPort/v1/pos?Action=EndOrder
http.action.cancel_order= https://cedIp:cedPort/v1/pos?Action=Cancel
http.action.status.check= https://cedIp:cedPort/v2/pos?Action=Status
http.action.get_tk = https://cedIp:cedPort/v2/pos?TransportKey=
http.action.keyed_sale = https://cedIp:cedPort/v1/pos?Action=InitiateKeyedSale
http.action.update_total= https://cedIp:cedPort/v1/pos?Action=UpdateTotal
http.action.discount_item=https://cedIp:cedPort/v1/pos?Action=DiscountItem
http.action.update_item =https://cedIp:cedPort/v1/pos?Action=UpdateItem
User loginID and PIN are stored encrypted in the EFTLink core configuration file.
As such the following property is required NOT to be altered:
ocius.properties=ocius.keystore
This is the default value (secure by default).
Logging of sensitive data defaults to secure settings and sensitive data is masked by default using the following setting:
MaskSensitiveDataLoggingEnabled=true
XML returned to the OPICore is also validated against a set of XSDs prior to parsing using the following setting:
ValidateOPIRetailResponse=true
By default all logging is secured as each core includes a number of sensitive fields included in communication which will be masked.
All logged communications information is also scanned for numbers which could possibly be full card numbers and are masked by default.
Trace level logging which is not enabled by default should not compromise security of the application.
The default logger should be configured for info only (debug information should not be generated in production environment)
This is configured in the log4j2.xml file:
<Loggers>
<Root level="info">
The application should be deployed with Java 1.8. Also the latest version of the java framework should also be deployed.
There are a number of issues which require the latest version of the framework to be used in order to ensure a secure deployment:
TLS 1.2 requires the use of Java 1.8
Enhanced Cryptography, ensuring better secured communications.
Use of earlier versions of the java framework may require the configuration of TLS and Crypto-agility to be altered which will result in decreased security.