3.3.1 Phần cứng
3.3.1.1 Sử dụng đơn vị chấp nhận thẻ độc lập
Vấn đề chấp nhận thẻ thanh toán hoàn toàn có thể được đáp ứng bởi một bên thứ 3 có vai trò tương tự như trọng tài thanh toán. Tuy nhiên, sự tham gia của bên thứ 3 này hoàn toàn mang tính chất bảo mật cho thẻ thanh toán như ở hình 11.
Hình 11: Kiểm soát thẻ bởi bên thứ 3
Trong cơ chế kiểm soát trong hình 11, có một trung tâm kiểm soát thẻ thực hiện những công việc kiểm tra tính hợp lệ của thẻ thanh toán trước khi cấp mã để giao dịch có thể được thực hiện.
Khi có sự tham gia của bên thứ 3, hệ thống ngân hàng sẽ được giảm tải rất nhiều do không phải xử lý khâu chấp nhận thẻ, sau khi thẻ được chấp nhận giao dịch với ngân hàng mới bắt đầu. Việc kiểm soát này hoàn toàn có thể thực hiện được bởi chính BANKNET. Tuy nhiên, không vì thế mà vấn đề bảo mật bị xem nhẹ, dữ liệu giao dịch vẫn phải đảm bảo được mã hóa và giải mã theo các tiêu chuẩn được quốc tế công nhận và
Trang 52 / 73
chung cho cả 3 bên, hiện nay mã hóa dữ liệu được sử dụng là RSA 7.1
3.3.1.2 Sử dụng mạng thanh toán riêng
Theo mô hình này, yêu cầu tách riêng hệ thống mạng ngân hàng với mạng thanh toán điện tử mà hiện vẫn đang dùng chung. Như vậy, kênh thanh toán ATM được xem như các kênh thanh toán mở rộng khác như thanh toán BANK-HOME thông qua Internet. Về mặt kết nối, hệ thống chỉ kết nối với máy chủ ngân hàng ở khâu hạch toán cuối cùng vào các tài khoản khách hàng.
Hình 12: Sự độc lập tương đối về mặt dịch vụ của mạng ATM
Sự độc lập tương đối của dịch vụ thanh toán tự động qua ATM (đối với các dịch vụ thanh toán khác của ngân hàng) được thể hiện trong hình 12 sẽ giúp tăng khả năng xử lý cho ATM đồng thời giảm tải cho các nghiệp vụ thanh toán khác của ngân hàng. Tuy nhiên, đây chỉ là sự độc lập tương đối trong mô hình tập trung.
3.3.1.3 Hạn chế sử dụng băng thông
Ta hãy xét đường đi của luồng thông tin trong giao dịch liên ngân hàng ở hình 13 trong mô hình thanh toán ATM đang sử dụng (ở hình 9
Trang 53 / 73
trang 45).
Hình 13: Đường đi của dữ liệu trong mô hình cũ
Với đường đi của dữ liệu thể hiện trên hình 13, chúng ta có thể nhận thấy quá trình hạch toán liên ngân hàng vô cùng phức tạp. Trước tiên, để có thể hạch toán từ máy ATM của ngân hàng bạn, dữ liệu sẽ phải đi qua ngân hàng chủ, sau đó gửi qua BANKNET để tới ngân hàng bạn. Để có thể hạch toán được, thông tin số tiền rút phải được chuyển tới cả hai hai ngân hàng và BANKNET để kiểm chứng. Như vậy, phải có hạch toán bước 2 để cân đối số liệu giữa hai ngân hàng. Khi hệ thống gặp sự cố không thể cân đối số liệu sẽ tạo kẽ hở trong thanh toán.
Ngay cả khi mô tả phần giao diện riêng với BANKNET thì cũng có thể nhận thấy trong mô hình trên khi thanh toán liên ngân hàng thông tin phải đi qua nhiều cấp và nhiều bước xử lý khiến giao dịch bị chậm và không an toàn. Hoàn toàn có thể hạn chế tối đa các thủ tục bắt tay nhiều cấp trong giao dịch khi sử dụng mô hình mới như kiến trúc trên hình 14.
Trang 54 / 73
Hình 14: Đường đi của dữ liệu trong mô hình mới
Trong mô hình này, sau khi được chấp nhận thanh toán luồng dữ liệu được định tuyến thẳng tới ngân hàng thanh toán mà không phải qua các hệ thống trung gian. Tất cả các dữ liệu tham số liên quan tới các ngân hàng thanh toán được lưu tại ATM. Tất nhiên, nếu là giao dịch liên ngân hàng rút tiền hoặc có tính phí hệ thống vẫn thực hiện giao dịch 3 tay để có cơ sở hạch toán và đối chiếu nhưng đây chỉ là khâu cuối cùng của dịch vụ, tất cả khác khâu trung gian của dịch vụ hoàn toàn không yêu cầu xử lý 3 tay cũng như không phải đi qua ngân hàng trung gian thanh toán gây mất thời gian và không an toàn.
Với hệ thống giao dịch này, quy trình hạch toán hoàn toàn tương đương với mô hình 1 cho thanh toán nội bộ, như vậy các yêu cầu thanh toán thời gian thực luôn được đảm bảo và phụ thuộc vào hệ thống riêng của mỗi ngân hàng.
Trang 55 / 73
3.3.2 Phần mềm
3.3.2.1 Sử dụng chuẩn giao dịch điện tử ISO 8583
Đây là chuẩn kết nối TCP/IP không mã hóa dữ liệu. Chuẩn này được chính thức áp dụng năm 1987 và coi như phiên bản chuẩn, mọi phiên bản sau đều tương thích với phiên bản này. Ban đầu phiên bản chỉ được xây dựng cho thanh toán cho ngân hàng điện tử nên có nhiều hạn chế, các phiên bản sau này được xây dựng cho thanh toán điện tử mở rộng (qua mạng di động và Internet). Đây cũng là chuẩn giao dịch của thẻ EMV (bao gồm cả VISA và Master Card cũng như các thẻ thông minh khác) và được phát triển trở thành chuẩn giao dịch điện tử của Ngân hàng Châu Âu năm 2002.
3.3.2.2 Cấu trúc Message
Hình 15: Cấu trúc một Message
Một Message có thể được biểu diễn với cấu trúc dạng khối (Block) như trên hình 15. Trong đó 4 byte đầu là mã Message – MTI (Message Type Indentifier) cũng được hiểu là tên Message. Tiếp theo là các khối dữ liệu gồm 64 trường bắt đầu bằng trường BITMAP 16 Byte (Hexa) xác định sự tồn tại hay vắng mặt của 64 trường dữ liệu. Trong trường hợp có khối tiếp theo thì có thêm một trường BITMAP mở rộng 16 byte (xem như mở rộng BITMAP thành 32 byte đối với khối đầu tiên). Kết thúc mỗi khối dữ liệu là 1 trường MAC 16 byte (Hexa) kiểm tra.
BLOCK
Trang 56 / 73
Thông thường, mỗi Message có 128 trường (2 block) – các trường phân cách nhau bằng ký tự „|‟ – định nghĩa nên tất cả các giao dịch cần có cho ngân hàng điện tử. Ngoài ra, cho phép sử dụng thêm 24 trường mở rộng (tùy chọn) lưu các thông tin phụ như mã „ISO‟, thông tin kiểm tra (check code), tên giao dịch hay độ dài Message … Có thể chia Message thành 2 loại như sau:
1. Message điều khiển (Sử dụng để Client bắt tay với hệ thống và đảm bảo sự liên tục và an toàn của phiên làm việc)
Message hỗ trợ kết nối: Logon, Logoff co Client yêu cầu được kết nối hệ thống
Message xác thực: Kiểm tra User, password, kiểm tra phiên làm việc (Do hệ thống yêu cầu Client xác nhận)
Message thông báo: Lỗi, bận, thông tin hệ thống (Do hệ thống thông báo tới Client)
2. Message giao dịch (Cho các yêu cầu cung cấp thông tin từ Client và thông tin trả lời của hệ thống)
Message vấn tin giao dịch
Message hạch toán (theo dịch vụ)
3.3.2.2.1 Phiên giao dịch trong ISO 8583
Một phiên giao dịch được định nghĩa bắt đầu từ bản tin yêu cầu kết nối từ phía Client và được Host cấp cho một số tương ứng với phiên làm việc và kết thúc bởi một bản tin xác nhận kết thúc từ phía Host cho Client. Mỗi yêu cầu có thể nhận được nhiều bản tin trả lời tùy thuộc vào từng giao dịch. Một phiên làm việc đơn giản nhất được mô tả như trên Hình 16.
Trang 57 / 73
Hình 16: Ví dụ phiên làm việc gồm logon và logoff [4]
Khi muốn truy nhập hệ thống, Client sẽ gửi một Message 0800 tới Host. Nếu chấp nhận (Client đáp ứng được các điều kiện) thì sẽ gửi trả cho Client một Message 0810. Tương tự như vậy, khi thoát khỏi hệ thống, Client gửi một Message 0800 tới Host và được xác nhận bằng Message 0810 kết thúc phiên làm việc.
3.3.2.2.2 Yêu cầu thời gian xử lý với ISO 8583
ISO 8583 yêu cầu thời gian không quá khắt khe cho các giao dịch điện tử nói chung. Với các giao dịch thông thường, các bản tin gửi từ Client tới cổng thanh toán thời gian được quy định không vượt quá 5s cho bản tin yêu cầu và 2 giây cho bản tin trả lời, nếu không đáp ứng được yêu cầu này bản tin nhận được (nếu có) được xem là không hợp lệ và phía phát tin sẽ nhận được thông báo lỗi hoặc yêu cầu gửi lại.
Trang 58 / 73
đến 60s và tùy thuộc vào từng Message (thậm chí trong một số trường hợp đặc biệt thời gian chờ có thể lên đến 120s nhưng không áp dụng cho các Message giao dịch). Ví dụ với giao dịch cho hệ thống thẻ thông minh: bản tin trả lời 0210, hệ thống Visa và Cirrus cho phép là 10s trong khi Master là 20s.
3.3.2.3 Mã hoá thông tin
Sử dụng giải pháp RSA SecurID cho xác thực khách hàng như một giải pháp chung cho bảo mật thông tin cá nhân. Giải pháp này được đánh giá rất cao trong thương mại điện tử hiện nay. Hệ thống sử dụng giải pháp này gồm 3 thành phần sau:
1. RSA SecurID® Authenticators: là thiết bị được gắn với người sử dụng, có thể là phần cứng hoặc phần mềm và được gọi là các Token.
2. RSA ACE/Agent Software: là phần mềm được cài lên trên các điểm truy cập vào mạng: gateway, VPN, máy chủ… là các tài nguyên thông tin cần được bảo vệ của doanh nghiệp. Khi có yêu cầu đăng nhập gửi đến, nó sẽ tiếp nhận và chuyển những thông tin đăng nhập tới máy chủ có thành phần RSA ACE/Server để thực hiện xác thực. Hầu hết các sản phẩm router, firewall, VPN, wireless access,... đều đã tích hợp sẵn thành phần này.
3. RSA ACE/Server: là thành phần quản trị của giải pháp RSA SecurID được sử dụng để kiểm tra các yêu cầu xác thực và quản trị tập trung trên mạng của doanh nghiệp.
Cơ chế xác thực của hệ thống sử dụng RSA SecurID dựa trên xác thực kép (như trên hình 17) bao gồm thời gian của một đồng hồ bên
Trang 59 / 73
trong mỗi thành phần (được khởi tạo theo giờ chuẩn UTC), một số Seed thường là 128 bit và số PIN của mỗi cá nhân làm đầu vào cho một thuật toán tạo số giả ngẫu nhiên để tạo thành mật khẩu hiện trên Token cho người sử dụng. Thông thường mật khẩu này sẽ thay đổi định kỳ một phút một lần.
Hình 17: Xác thực kép thay cho sử dụng mã PIN
Ngoài rất nhiều ưu điểm của giải pháp này như độ an toàn, sự đơn giản, tiện lợi, chi phí thấp…. thì điểm được khách hàng đánh giá cao nhất là họ không phải thay đổi mật khẩu định kỳ theo yêu cầu từ phía ngân hàng.