• No results found

Secure web transactions system

N/A
N/A
Protected

Academic year: 2021

Share "Secure web transactions system"

Copied!
6
0
0

Loading.... (view fulltext now)

Full text

(1)

Secure web transactions system

TRUSTED WEB SECURITY MODEL

Recently, as the generally accepted model in Internet application development, three-tier or multi-tier applications are used. Moreover, new trends show that most of these applications are web-based applications. In this sense, a typical three-tier web Internet application, see Fig. 1, consists of clients, web server and database server. In this model, client is always an Internet browser program and web server could be web server only or a combination of the web and application server.

Figure 1: A simplified block diagram of the typical web Internet three-tier application architecture

Security mechanisms in this architecture consist of two segments:

ƒ Security segment for communication security between client and web server,

ƒ Security segment for communication and access protection between web/application server and database server.

Security part between client and server is realized by implementing security mechanisms on application and transport layers in the Secure Web Transaction (SWT) environment.

Security solution for communication security between web/application server and database server is realized by using Cryptographic Proxy Gateways (CPG) as proprietary application level security gateway firewall with two Ethernet interfaces. CPG should be used as the last defense in front of data sensitive financial database server. If the system uses both WEB and application servers, CPG should be placed between the application and database server. Modern security trends request the application of the proprietary firewalls that offer greater level of security, instead of standard commercial ones, for this purpose.

. . . Internet WEB/Application server Client n Client 1 WEB server Database server Application server

(2)

SECURE WEB TRANSACTION SYSTEM

Secure WEB transaction system (SWT) is designed to cryptographically enhance any WEB server to browser communication by implementing originally developed cryptographic functions. SWT is a NetSeT’s proprietary system which is, in the transport level part, similar to the standardized and widely used SSL protocol. However, SWT system has four main advantages compared to SSL protocol:

ƒ SWT system includes data protection on the application level based on asymmetric (e.g. RSA with ≥1024 bits key length) and symmetric cryptographic algorithms,

ƒ SWT includes a proprietary server-browser authentication procedure, “stronger” than the one applied in SSL, for establishing cryptographic tunneling,

ƒ SWT includes originally developed symmetric cryptographic algorithms for data protection on transport level with encryption key length (≥ 256 bits) larger than the keys used in SSL protocol (40 or 128 bits key length). SWT system also offers three possible options for symmetric cryptographic algorithms: public algorithms (DES, 3DES, RC2, RC4, IDEA, AES), proprietary SCA-13 NetSeT’s algorithm with very long non-linear pseudo-random noise sequence (>>10100), and user’s defined symmetric algorithm,

ƒ SWT system is fully verifiable on the source code level.

Additionally, SWT system is associated with smart card readers both on the client’s and server’s side and has also implemented the originally developed user “strong” authentication procedure. Client parts of SWT system are designed both for Windows and Linux-based operating systems. In the SWT system, a combination of the cryptographic tunnel on the transport level and application level protection based on symmetrical and asymmetrical cryptographic algorithms is used, see Fig. 2. In this sense, SWT system consists of the transport SWT module and application SWT module.

NetSeT 's SWT system for secure WEB communication is scalable and could consist of the following solution categories:

ƒ A system based on the SWT smart card based application level protection and “open” (unsecured) transport level communication,

ƒ A system based on the SWT smart card based application level protection and SSL security protocol on transport level based on digital certificates generated by NetSeT’s Certification Authority system,

ƒ A system based on the SWT application and transport level protection on the basis of smart cards completely provided by NetSeT – the complete SWT system.

(3)

Figure 2: SWT system’s stack

TRANSPORT SWT MODULE

This module is based on proprietary cryptographic proxy components for both on the client and server side. By applying these components, a protected communication channel – cryptographic tunnel based on symmetrical cryptographic algorithm is established. This tunnel is established only if the proprietary bilateral strong authentication procedure between client and server is successfully realized. This challenge-response authentication procedure is cryptographically stronger than the one used in SSL protocol and it is based on symmetrical and asymmetrical cryptographic algorithms, two session keys and X.509 digital certificates for both client and server.

HTTP AUTHENTICATION SERVER

Transport SWT module is a basis of the HTTP authentication server with the following main features:

ƒ Transport SWT module could be used for protection of the WEB/application server used for specific business application,

ƒ HTTP authentication server used proprietary protocol for communication with clients on the top of the HTTP protocol,

ƒ Direct access to the WEB server is forbidden for outside world and only HTTP authentication server has a connection to the WEB business server, ƒ Accordingly, access to the WEB server is forbidden for all users except the

ones that have special gateway – HTTP proxy client,

ƒ HTTP proxy client and HTTP authentication server are based on smart cards and strong authentication procedures between client and server, ƒ

TCP/IP

Transport SWT module

Application Network Application SWT module

(4)

validation, uses the CRL published on the LDAP server or Active Directory server.

APPLICATION SWT MODULE

This module is used for realization of two main functions:

ƒ User strong authentication based on PKI bilateral challenge-response procedure,

ƒ End-to-end security on the application level based on digital signature and digital envelope technologies using asymmetrical and symmetrical cryptographic algorithms.

This module realizes functions for digital signature of the application data (providing authenticity, integrity protection and non-repudiation) and encryption (providing confidentiality protection). Namely, NetSeT’s cryptographic application programming interface (API) is a set of the asymmetric and symmetric cryptographic functions which could be implemented in any of the user’s applications, designed for Windows 98/NT/2000/XP and Linux platforms. This set consists of the following main functions:

ƒ Digital signature (RSA algorithm with a key ≥1024 bits), ƒ Verification of the digital signature,

ƒ Encryption (use of standard, NetSeT’s proprietary or user’s defined symmetric algorithms),

ƒ Decryption,

ƒ Communication with smart card reader with implemented authentication functionality,

ƒ User’s authentication.

These API functions are fully compatible with existing de facto standards – PKCS (Public Key Cryptographic Standards), such as: PKCS#1, PKCS#7 and PKCS#11. Besides the user strong authentication functions mostly implemented in the WEB server environment or in front of the WEB server (HTTP authentication server), application level security mechanisms enable “end-to-end” security between the client and application server that is mostly located in a domain behind the web server (it is located on application server or even directly on the database server). On the other side, SSL protocol provides security only between the client and web server, and all the data running over the internal network (behind the WEB server) is in clear. The SWT application level security module is realized as an ActiveX component or JAVA applet both for the client and server side. In fact, client modules are mostly ActiveX components (since Windows clients are prevalent) while servers’ sides are ActiveX for Windows or JAVA servlet for JAVA environments. These components are installed on the client side; they are integrated into the html pages and activated through client’s Internet browser program.

(5)

Two working modes are possible, regarding the type of the application. Namely, it is possible to protect data in the interactive communication between client and server (on-line) or protection of data or files could be provided in advance (prepared signed and encrypted files) through some off-line cryptographic procedure. Both on-line and off-line procedure use the same ActiveX (or JAVA applet), but in the different environment (on-line is used through Internet browser program and off-line is used through some specialized off-line cryptographic application).

The components of the SWT system are based on a modular structure and both of them have an application and transport SWT module. The main difference between the two SWT components is in the server and client’s local application interface (SWAL – Secure Web Application Link) that has a purpose of integrating these components into the WEB application. SWAL module enables WEB applications the use of the set of cryptographic API functions, necessary for the application level protection.

In order to additionally improve the functionality and overall security of the server side of the SWT system, a PCI card-based crypotgraphic coprocessor solution, called NST2000, is to be implemented. The hardware security modules, realized as coprocessors, represent strong points of the modern security solutions for the computer networks. The existence of hardware security modules is ultimate for design of the computer network system with high performance and high level of the security. In that case, the encryption algorithms and the other security related functions (e.g. access control functions) are securely executed on the hardware element and sensitive data are never loaded on the user’s computer memory. Without these modules, it would not be possible to achieve the trusted aplication concept with a full control of the system access and resistant to the Trojan Horse attacks. It is proven that PC operating systems and other system software components have some security drawbacks, and this is especially critical for the software-only cryptographic tools.

CPG AS THE APPLICATION LEVEL FIREWALL IN THE TRUSTED WEB SECURITY MODEL

In the trusted WEB security model, CPG is used for protection of the back-office second model segment – namely, for communication protection between the WEB/application server and database server. In this configuration, a simplified block-diagram is given on Fig. 3, it is necessary to implement a special cryptographic component on the WEB/application server, named CPG gateway, which is used for establishing secure communication (strong user authentication and cryptographic tunnel) between WEB/application server and database server. In this way, all communication between WEB/application server and database server is encrypted and only servers with CPG gateway could have access to the database server.

(6)

Figure 3: Security protection between WEB/application server and database server W EB СЕРВЕР БОНИТЕТ СЕРВЕР БАЗЕ БОНИТЕТ DeMilitarized Zone (DMZ) Crypto API Internal network

ПККС

W EB or application server Database server CPG Gateway

CPG

References

Related documents

When to use: User application failures, application server failures, HTTP errors, application server hangs, unavailable application servers, timeout errors in a Web browser?. It

application development rates, apache web server for mac, apache web server security configuration, web hosting service level agreement template, sms marketing software

Apart from basic security functionality, it contains objects that provide high-level security functions, such as: local authentication of the user, smartcard handling,

Network Firewalls Do Not Work For HTTP Firewall Port 80 HTTP Traffic Web Client Web Server Application Application Database Server...

How attackers look at web apps User Application server Database server Authentication File server Bypass Session fixation XSS CSRF JSON hijacking Logic flaws Path traversal

Web application LDAP to auth ⇒ ⇑ pass control user's browser → HTTP Server Apache identity management server.. Web

Subscribe Online Shopping Customer Service Trading Web Services/ B2B Your Workload Infrastructure Component Edge Server Web Presentation Server Web Application Server Security

 (Non-)persistent user state is stored on the server under the unique session id.. source ip, source port, user-agent, …).  Additional application-level authentication per