Mô hình tích hợp hệ thống CA với hệ thống IBPS:
Hình 7.1: Mô hình tích hợp hệ thống CA với hệ thống IBPS
Hệ thống CA được triển khai tại NPSC và các PPC và hoạt động song song với hệ thống thanh toán điện tử liên ngân hàng (IBPS).
- Hệ thống CA được cài đặt tại tất cả các điểm NPSC, BNPSC và tất cả các PPC. Việc này đảm bảo cung cấp kịp thời và nhanh nhất các thông tin cần thiết cho hệ thống IBPS hoạt động, đảm bảo tốc độ xử lý các yêu cầu gửi tới từ hệ thống IBPS.
- Hệ thống CA hoạt động 24/24 và luôn có dữ liệu đồng nhất trên các điểm cụ thể của hệ thống IBPS. Bất kỳ thay đổi nào về thông tin của các chứng thư số cũng sẽ được cập nhập tức thời tại các vùng hệ thống IBPS hoạt động.
- Tổ chức một Sub CA cho hệ thống IBPS, tại NPSC cũng như các PPC thiết lập các LDAP server để lưu trữ thông tin về chứng thư số. Trao đổi thông tin giữa hệ thống IBPS và hệ thống CA sẽ được thực hiện theo cơ chế là trao đổi thông tin với các LDAP server đặt tại điểm đó.
- Tại các điểm PPC, việc thiết kế năng lực của LDAP server đã được tính đến yếu tố: các CI của ứng dụng IBPS sẽ truy cập thông tin khóa công khai từ LDAP server đặt tại PPC mà CI đó kết nối.
Hình 7.2: Giao diện với hệ thống IBPS
Hệ thống CA cung cấp các hàm API chuẩn, cho phép hệ thống IBPS sử dụng các ngôn ngữ lập trình C/C++, Java, Delphi, .NET … có thể trao đổi dữ liệu với các LDAP server. Các hàm API cung cấp cho các hệ thống ngoài sẽ bao gồm:
- Hàm lấy khóa công khai của một chứng thư số - Hàm kiểm tra tính hiệu lực của chứng thư số - Hàm lấy thông tin người dùng chứng thư số - Hàm ký trên dữ liệu
- Hàm xác thực dữ liệu
Hệ thống CA sẽ tạo ra cho mỗi người sử dụng hệ thống (đặc biệt là Kiểm soát liên hàng tại CI) một cặp khóa: Kr (khóa bí mật) và Ku (khóa công khai). Khóa bí mật chỉ được lưu trong token sẽ chuyển cho người sử dụng, còn khóa công khai sẽ được lưu giữ trong cơ sở dữ liệu quản lý tất cả các khóa Ku của mọi người dùng.
- Người sử dụng sẽ sử dụng khóa bí mật Kr để tạo chữ ký số của mình thay cho E-Sign hiện tại.
- Điều này nhằm khắc phục được các điểm cần được cải tiến đã nêu trong Nhận xét 1 ở phần trên, tức là đảm bảo tính chống chối bỏ (non-repudiation) đối với xác thực dữ liệu và thực hiện được việc xác thực từ điểm đầu đến điểm cuối (End-to-end).
Hình 7.3: Xác thực với mã khóa công khai7.2 CÁC TIẾN TRÌNH XỬ LÝ 7.2 CÁC TIẾN TRÌNH XỬ LÝ
7.2.1 Đồng bộ chứng thư số và danh sách chứng thư số bị thu hồi.
7.2.1.1 Đồng bộ chứng thư số đầu ngày
Hình 7.4: Quy trình đồng bộ chứng thư số đầu ngày
Mô tả
- Chứng thư Root CA sẽ được copy lên phân vùng của hệ thống IBPS
- Đầu ngày download ARL và Sub CA với các DN đã định nghĩa trước trên hệ thống IBPS. Kiểm tra trong ARL và xác thực chứng thư sub CA để biết Sub CA có hiệu lực hay không. Nếu Sub CA không có hiệu lực => Cập nhật tất cả các chứng thư số hiện tại của người dùng không còn hiệu lực.
- Tìm kiếm trong LDAP danh sách tất cả các DN người ký duyệt hệ thống IBPS. Kết quả trả về có các thông tin: DN, Bank_code, ApproverID và chứng thư của người dùng tương ứng. Xác thực chứng thư số của người ký duyệt.
- Ghi file chứng thư mới và Cập nhập bảng thông tin chứng thư: Bank_code, ApproverID, DN, SerialNumber, DN-CRL, trạng thái Revoke, thời điểm Revoke (Cho các chứng thỉ mới hoặc có thay đổi). Các chứng thư của một người ký duyệt được quản lý tại PPC bao gồm cả các chứng thư còn hiệu lực và các chứng thư đã bị thu hồi.
- Kiểm tra giá trị HMAC để tạo file chứa chứng thư và các thông tin liên quan cho các chứng thư mới hoặc thay đổi trạng thái gửi CI.
- Tạo file chứa chứng thư và các thông tin liên quan cho các chứng thư mới hoặc thay đổi trạng thái gửi CI.
- Tại CI cập nhập file chứng thư và các thông tin liên quan.
- Lưu trạng thái chạy tiến trình cập nhật chứng thư số đầu ngày trong bảng CERT_PROC.
7.2.1.2 Cập nhật chứng thư số mới trong ngày
Quy trình thực hiện
Hình 7.5: Quy trình đồng bộ chứng thư số trong ngày
Mô tả
- Đặt thời gian chạy nhiều lần trong ngày.
- Download toàn bộ chứng thư số và thêm mới thông tin chứng thư số mới. - Kiểm tra các chứng thư số đã hết hạn, tính HMAC và cập nhập thay đổi. - Kiểm tra giá trị HMAC tạo file gửi các CI với các chứng thư mới và các
chứng thư thay đổi trạng thái.
- Lưu trạng thái chạy tiến trình cập nhật chứng thư số mới trong bảng CERT_PROC.
7.2.2 Quy trình ký và xác thực tin điện tại PPC
7.2.2.1 Xác thực giao dịch đi tại O-PPC
Quy trình thực hiện
Hình 7.6: Quy trình xác thực tin điện tại PPC
Mô tả
- Kiểm tra ngân hàng gửi có tham gia CA hay không.
Lấy và kiểm tra dữ liệu về chứng thư số của người ký duyệt tin điện trong CSDL. Nếu dữ liệu vê chứng thư số bị thay đổi thì thông báo lỗi.
Kiểm tra tính hiệu lực chứng thư số của người ký duyệt. Nếu chứng thư số hết hiệu lực thì thông báo lỗi.
Xác thực chữ ký trên giao dịch nếu không thành công thì thiết lập trạng thái giao dịch là lỗi.
Gắn giờ xác thực trên PPC lên tin điện được xác thực.
o Nếu ngân hàng gửi không tham gia CA:
Thực hiện xác thực tin điện bằng mã xác thực.
7.2.2.1 Ký giao dịch đến tại R-PPC
Quy trình thực hiện
Hình 7.7: Quy trình ký tại PPC
Mô tả
- Nếu ngân hàng gửi có tham gia CA:
o Trường hợp ngân hàng nhận tham gia CA: Không thực hiện ký giao dịch đến.
o Trường hợp ngân hàng nhận không tham gia CA: Thực hiện ký giao dịch đến bằng mã xác thực.
- Nếu ngân hàng gửi không tham gia CA:
o Trường hợp ngân hàng nhận tham gia CA: Thực hiện ký giao dịch đến bằng khóa Private Key của thực thể PPC.
o Trường hợp ngân hàng nhận không tham gia CA: Thực hiện ký giao dịch đến bằng mã xác thực.
7.2.3 Quy trình ký và xác thực tin điện đối với CI sử dụng chứng thư số
7.2.3.1 Ký trên tin điện gửi đi
Quy trình thực hiện
Mô tả
- Tại CI khi cần ký duyệt giao dịch người ký duyệt phải cắm iKey của mình vào máy
- Kiểm tra IKEY có hợp lệ. IKEY không hợp lệ bao gồm:
o IKEY không chứa khóa ký.
o IKEY lưu khóa ký của tổ chức khác không thuộc hệ thống CA của ngân hàng nhà nước cấp.
o IKEY lưu nhiều khóa ký (từ 2 khóa trở lên).
- Kiểm tra thông tin của người ký duyệt tin điện trong Cơ sở dữ liệu có bị thay đổi, nếu có sự thay đổi thì thông báo lỗi.
- Kiểm tra thông tin SerialNumber của chứng thư trên iKey xem có tương ứng với người đang thực hiện ký duyệt thì mới cho phép thực hiện tiếp. Nếu sai, thông báo cho người ký duyêt
- Kiểm tra tình trạng thu hồi chứng thư trên cơ sở dữ liệu tại CI, nếu còn hiệu lực thì cho phép thực hiện tiếp. Nếu sai, thông báo người ký duyệt
- Ký duyệt giao dịch: gắn thêm vào giao dịch các thông tin: Chữ ký số, SerialNumber, Thời điểm thực hiện ký
7.2.3.2 Xác thực tin điện đến
Hình 7.9: Quy trình xác thực tại CI
Mô tả
- Để kiểm soát tin điện đến, người kiểm soát phải cắm IKEY để kiểm tra quyền kiểm soát của người đó.
- Kiểm tra thông tin về người kiểm soát có hợp lệ bao gồm:
o IKEY hợp lệ
o Thông tin trong IKEY và người kiểm soát có hợp lệ.
- Lấy và kiểm tra thông tin về người ký duyệt (ngân hàng gửi) tin điện có bị thay đổi.
- Xác thực lại chứng thư số của người ký duyệt (ngân hàng gửi) có hợp lệ. - Kiểm tra chứng thư số của người ký duyệt (ngân hàng gửi) có còn hiệu lực:
o Nếu chứng thư còn hiệu lực: Thực hiện xác thực tin điện
o Nếu chứng thư số hết hiệu lực, so sánh thời điểm xác thực tại PPC và thời điểm chứng thư số bị thu hồi.
Nếu thời điểm xác thực tại PPC < thời điểm chứng thư số bị thu hồi: Thực hiện xác thực tin điện
Nếu thời điểm xác thực tại PPC >= thời gian chứng thư số bị thu hồi: Thông báo lỗi.
7.2.3.3 Xử lý file đồng bộ chứng thư số tại CI
Quy trình thực hiện
Mô tả
- File PCA từ trên PPC sẽ được chuyển đến các CI.
- Tại CI, khi nhận file PCA về sẽ lần lượt đọc các thông tin chứng thư số trong file PCA và kiểm tra chứng thư số này có phải là Sub CA hay không? Có 2 trường hợp:
o Nếu là Sub CA thì kiểm tra Sub đó đã tồn tại trong Cơ sở dữ liệu chưa ? Nếu chưa tồn tại thì tạo ra MAC của chứng thư số và thêm thông tin chứng thư số đó (gồm cả MAC) vào Cơ sở dữ liệu. Nếu đã tồn tại thì tạo lại MAC của chứng thư số và cập nhập thông tin chứng thư số đó (gồm cả MAC mới) vào Cơ sở dữ liệu.
o Nếu không phải là Sub CA thì kiểm tra Serial của chứng thư số đã tồn tại trong Cơ sở dữ liệu chưa? Nếu chưa thì tạo MAC và nhập thông tin chứng thư số (gồm cả MAC) vào cơ sở dữ liệu. Nếu đã tồn tại thì tạo lại MAC và cập nhập thông tin chứng thư số (gồm cả MAC mới) vào cơ sở dữ liệu.
- Kết thúc quá trình cập nhập file PCA.
7.3 ĐÁNH GIÁ
Mô hình hệ thống IBPS sau khi tích hợp với hệ thống CA:
Hình 7.11: Hiện trạng bảo mật hệ thống IBPS khi tích hợp
- Hệ thống IBPS đã cải thiện và nâng cao tính hiệu quả của các biện pháp bằng mã khóa công khai khi tích hợp với hệ thống CA.
- Tốc độ xử lý của hệ thống IBPS sau khi tích hợp tăng không đáng kể. Thời gian thực hiện một giao dịch ~ 10 giây
- Vẫn đảm bảo được các đặc tính kỹ thuật:
o Kiến trúc hệ thống mở
o Phương thức giao dịch trực tuyến (on-line)
o Tuân thủ các chuẩn quốc tế
o Sẵn sàng cao (99.99%)
o An toàn dữ liệu, bảo mật cao
o Dễ vận hành, giao diện sử dụng thân thiện
o Sẵn sàng kết nối với các hệ thống khác
7.3.1 Vấn đề ‘Mã xác thực, dấu hiệu điện tử và việc xác thực dữ liệu’
Xem xét việc giải quyết vấn đề ‘Mã xác thực, dấu hiệu điện tử và việc xác thực dữ liệu’ (chương 6 - mục 6.2.1)
Xác thực dữ liệu
Hiện tại hệ thống tích hợp đã giải quyết vấn đề cần cải tiến được nêu trong nhận xét 1 (Chương 6 - mục 6.2.1), tức là đảm bảo tính chống chối bỏ (non-repudiation), nhưng vẫn còn tồn tại các vấn đề.
- Do hệ thống vẫn tồn tại đồng thời cơ chế xác thực bằng mã xác thực (AAC), dấu hiệu điện tử (trong trường CI gửi tin điện hoặc CI nhận tin điện chưa đồng thời sử dụng mã khóa công khai).
- Phát sinh việc tạo chữ ký cho tin điện tại R-PPC bằng khóa bí mật của R- PPC (Chương 7 - mục 7.2.2.2), khi CI gửi tin điện chưa dùng mã khóa công khai và CI nhận tin điện đã sử dụng mã mã khóa công khai. Điều này lặp lại vấn đề được nêu trong nhận xét 1 (Chương 6 - mục 6.2.1)
Nhận xét 3:
- Chưa bảo đảm được tính chống chối bỏ (non-repudiation) đối với xác thực dữ liệu trong trường hợp ngân hàng gửi hoặc ngân hàng nhận không dùng cùng cơ chế xác thực bằng mã khóa công khai.
Xác thực điểm đầu đến điểm cuối
- Việc đồng bộ dữ liệu từ LDAP:
o Tại các CI là không trực tiếp, nó được thực hiện thông quan hệ thống IBPS (Inter-Bank Payment System)
o Tại PPC/NPSC sẽ thực hiện vào đầu ngày và theo khoảng thời gian cố định. Do đó dữ liệu LDAP tại PPCs/CIs không đáng tin cậy (tại thời điểm xử lý xác thực dữ liệu này không làm mới nhất).
- Do dữ liệu LDAP là không tức thời, cho nên không đảm bảo hoàn toàn việc xác thực điểm đầu đến điểm cuối (End-to-end).
- Không đảm bảo hoàn toàn việc xác thực từ điểm đầu đến điểm cuối (End-to- end), do cơ chế cập nhật dữ liệu LDAP.
7.3.2 Vấn đề ‘Xác thực thực thể và mã hóa dữ liệu trong quá trình truyền thông’ thông’
- Vấn đề được nêu trong Nhận xét 2 (Chương 6 - mục 6.2.2) chưa được giải quyết, vấn đề mã hóa dữ liệu trong quá trình truyền thông vẫn chưa được mã hóa bởi khóa công khai.
7.3.3 Vấn đề khác
- Hệ thống không thực việc quản lý nhãn thời gian. Do đó thời gian là khác nhau giữa: hệ thống CA + Hệ thống IBPS + CIs.
- Các vấn đề về xác thực chứng thư số Root CA, Sub CA, CIs. - Các vấn đề về nội dung dữ liệu được đồng bộ từ LDAP:
o Chỉ thực hiện đồng bộ vào đầu ngày
Chứng thư số root CA.
ARL (Authority Revocation List) root CA.
Chứng thư số sub CA.
CRL (Certificate Revocation List) sub CA.
Chứng thư số CIs.
o Trong ngày chỉ thực hiện đồng bộ:
Chứng thư số sub CA.
CRL (Certificate Revocation List) sub CA.
CHƯƠNG 8
ĐỀ XUẤT CÁC GIẢI PHÁP CHO HỆ THỐNG TÍCH HỢP
Chương này sẽ trình bày các giải pháp đề xuất cho hệ thống tích hợp nhằm mục đích nâng cao hiệu quả an toàn bảo mật của hệ thống IBPS.
8.1 ĐẶT VẤN ĐỀ
Hệ thống thanh toán điện tử liên ngân hàng là một hệ thống có những yêu cầu rất cao về bảo mật. Để bảo đảm tính đáng tin cậy và khả năng hoạt động liên tục của hệ thống trong môi trường mạng có nhiều nguy cơ đe dọa, nhiều biện pháp an toàn và bảo mật đã được thực hiện. Riêng ở tầng ứng dụng (trong mô hình tham chiếu OSI 7 tầng đối với truyền thông trên mạng [1]), các yêu cầu sau đây cũng đã được đặc biệt chú ý:
- Đảm bảo tính toàn vẹn (integrity) cho dữ liệu: xác định được dữ liệu bị thay đổi nội dung sau khi đã được phát hành trong mỗi giao dịch hoặc sự thay đổi nội dung trong quá trình lưu trữ.
- Đảm bảo tính chống chối bỏ (non-repudiation): người tham gia giao dịch sẽ không chối bỏ được thông tin đã đưa vào giao dịch.
- Đảm bảo tính xác thực (authentication) của các cá nhân tham gia giao dịch, tránh việc giả mạo, mạo danh khi giao dịch.
- Đảm bảo tính mật (confidentiality) của giao dịch bằng cách mã hóa.
Hiện tại, hệ thống IBPS đã được tăng cường các biện pháp an toàn bảo mật và ứng dụng mã khóa công khai, bằng việc tích hợp hệ thống CA NHNN. Tuy nhiên, vẫn còn tồn các vấn cần được (chương 7 - mục 7.3). Từ những phân tích đánh giá hiện trạng hệ thống tích hợp (chương 7) so với các vấn đề an toàn bảo mật của hệ thống IBPS trước khi tích hợp với hệ thống CA của ngân hàng nhà nước Việt Nam (chương 6), nhằm cải tiến và nâng cao hiệu quả an toàn bảo mật của hệ thống IBPS tôi đề xuất các giải pháp:
- Loại bỏ hoàn toàn cơ chế xác thực bằng mã xác thực (AAC), dấu hiệu điện tử, hệ thống tích hợp chỉ dùng cơ chế xác thực dùng mã khóa công khai. - Vấn đề xử lý nghiệp vụ và xác thực tại PPC
- Tăng cường bảo mật dữ liệu đường truyền sử dụng mã khóa công khai.