Quản lý khóa là một vấn đề quan tr ng khi thiọ ết kế ộ m t giao thức xác thực. Phương pháp dùng để sinh ra và lưu trữ một lượng l n các khóa xác ớ thực của người dùng và xử lý các yêu cầu xác thực rất quan tr ng trong viọ ệc đảm b o m t h th ng SMS banking an toàn. Trong các giao thả ộ ệ ố ức dư i đây, ớ giải pháp s s dẽ ử ụng hệ thống khóa đối xứng. So với hệ thống đối xứng, hệ thống khóa mã hóa bất đối xứng yêu c u quá nhi u các phép toán phầ ề ức tạp, trong khi lại ph i tả ối ưu dung lượng sử ụ d ng trên máy cầm tay. Đối với các nư c đang phát triớ ển như Vi t Nam, đ i đa sệ ạ ố ngư i dùng đờ ều không có khả năng sử ụ d ng các mẫu điện tho i cao c p vớạ ấ i dung lượng bộ nhớ ớ l n, vì vậy vấn đềtiết kiệm dung lượng lại càng phải chú ý hơn nữa.Vì những lý do đó để ứng d ng này s thu hút ngưụ ẽ ời dùng v i r t nhi u loớ ấ ề ại điện tho i khác nhau, ạ chúng ta s dử ụng hệ ố th ng mã hóa đối xứng. Quản lý khóa bao gồm sinh khóa, lưu trữ, phân b , xóa, nén và qu n lý các ứố ả ng d ng c a khóa. ụ ủ
68
4.3.1 Sinh khóa
Phương thức sinh khóa có thể chia làm 2 loại. Cách thứ nhất là dùng b ộ sinh số ngẫu nhiên, cách th hai là sinh khóa tứ ừ ữ ệ d li u người dùng theo một thuật toán nào đó.
Giao dịch kiểm tra số dư và chuyển kho n cả ần sử ụ d ng một b sinh mộ ật khẩu m t lần (chính là khóa mã hóa)ộ . Ứng dụng sinh mật khẩu được ngân hàng quản lý. Bộ sinh s s tố ẽ ạo ra một danh sách các mật khẩu ng u nhiên ẫ trên cơ sở ộ ố ự ự m t s th t cho trước. Các s này s đưố ẽ ợc trao đổi theo cách mà chỉ có ngân hàng và các khách hàng dùng dịch vụ biết. Danh sách này sẽ được sinh ra và lưu trong một file, g i tử ới người dùng theo một kênh thông tin bảo mật khi có yêu cầu.
Đố ới v i phương pháp sinh mật kh u d a trên m t s seq duy nh t cho ẩ ự ộ ố ấ toàn hệ ố th ng thì s seq này phố ải r t lấ ớn, gây bất tiện cho khách hàng. Mật khẩu này cũng sẽ được sinh sẵn và chờ cung c p cho các khách hàng. Cách ấ làm này n tdẫ ới b t tiấ ện cho qu n lý khóa và không tả ối ưu với các hệ ố th ng lớn. Cách thứ hai là sinh khóa dựa trên số seq theo từng khách hàng. Khi khách hàng mu n số ử ụ d ng dịch vụ trên số tài khoản nào thì hệ ố th ng sẽ sinh s ố seq-mật khẩu và cung cấp cho khách hàng. Cách làm này đã khắc phục được các như c điợ ểm nêu trên.
Trong giao d ch ki m tra tài kho n, các khách hàng sị ể ả ẽ mã hóa b n tin ả yêu c u bầ ằng chính mật khẩu một lần ho khóa sinh ra tặc ừ ậ m t khẩu một lần kết hợp với PIN của khách hàng. Ngân hàng sẽ ử g i b n tin trả ả ờ l i đã được mã hóa b ng khóa sinh ra tằ ừ ự ế s k t hơp của PIN khách hàng, số Salt, và s tài ố khoản. Khi người dùng nhận được bản tin trả ờ l i, họ ẽ s nhập vào c PIN và sả ố tài khoản để có th ể xem được nội dung của bản tin. Ưu điểm của vi c này là ệ
69
không c n phầ ải lưu trữ các khóa mã hóa b n tin trả ả ề v do đó sẽ tiết kiệm chỗ lưu trữ trên thi t b ế ịdi động.
Trong giao dịch chuyển khoản, yêu cầu của khách hàng cũng sẽ được mã hóa theo m t trong hai cách nêu trên. Phộ ần trả ờ l i của ngân hàng sẽ được mã hóa và giải mã theo như những thủ ụ t c giống với giao dịch kiểm tra số dư. 4.3.2 Lưu trữkhóa
S ố thứ ự t và mật khẩu sinh ra đư c lưu trong cơ sợ ở d ữ liệu riêng và được quản lý bởi ngân hàng. Ứng dụng sinh mật khẩu sẽ đồ ng thời n i v i ố ớ CSDL lưu trữ chúng t i thạ ời điểm sinh m t kh u. Các mậậ ẩ t kh u và s th t ẩ ố ứ ự đã dùng rồ ẽi s được xóa khỏi CSDL sau m t khoảng thời gian nhấ ịộ t đnh để tiết kiệm bộ nh . Nếớ u người dùng bị m t danh sách các mậấ t khẩu thì người dùng có thể yêu c u lại một ầ danh sách m i và phía máy chớ ủ ẽ s lưu trữ danh sách mới thay vì danh sách cũ.
Ngoài ra, nếu mật kh u dùng m t l n và s th t tương đưẩ ộ ầ ố ứ ự ợc sinh d a ự trên t ng tài khoừ ản thì có thể ế ti t kiệm bộ nhớ phía máy ch b ng cách không ủ ằ lưu hết danh sách m t kh u và s th t này. C th ậ ẩ ố ứ ự ụ ể là, đối v i m i s tài ớ ỗ ố khoản sẽ có một khóa dùng để sinh khóa. T i thạ ời điểm sinh m t khậ ẩu cho khách hàng, khóa này sẽ ế k t hợp với số seq đểcho ra mật khẩu tương ứng và gửi lại cho khách hàng, tuy nhiên lại không lưu trữtrên cơ sở ữ ệ d li u. Khi có yêu c u giầ ải mã, ứng dụng máy chủ ẽ s tìm khóa tương ng đó, kứ ết hợp với số seq gửi về để tìm ra m t khậ ẩu tương ứng. Với cách làm này, chúng ta sẽ ế ti t kiệm được rất nhiều dung lượng cho máy chủ cơ sở ữ ệ d li u, nhất là với các cơ s d ở ữliệu mà có s ố lượng tài khoản lớn. Giả ử, s h ệ thống có 1.000.000 khách hàng, mỗi khách hàng khi đăng kí sử ụ d ng dịch vụ được cấp 100 mật khẩu, con số m t khẩậ u phải lưu là một vấn đề ớ l n. Như v y, đây thậ ật sự là m t ộ
70
phương án đáng lưu ý khi thiế ết k các h th ng lớnệ ố , và cũng là phương án mở rộng hệthống mà vẫn tiết kiệm được tài nguyên.
4.3.3 Quản lý khóa
Một khách hàng đăng kí dịch vụ ới ngân hàng cần phải có tài khoản v trong ngân hàng và tự ch n một số nhận dạọ ng PIN cho mình mà chỉ có khách hàng và ngân hàng biết. S ố PIN này thường có độ dài 4 hoặc 6 ký tự. Đa số các hệ thống đều sử ụ d ng PIN có 6 ký tự để đả m bảo an toàn cho người sử dụng mà vẫn dễ nhớ. PIN của khách hàng có thể trùng nhau. Tại phía ngân hàng cũng sẽ phải lưu số này của khách hàng để xác th c tài khoản. ự
Người dùng khi đăng kí sẽ nhận được m t danh sách các m t kh u ộ ậ ẩ dùng một lần và và một danh sách các số ứ ự th t tương ứng t ừphía ngân hàng.
Người dùng có th n ngân hàng nh n m t cách tr c ti p ho c nhể đế ậ ộ ự ế ặ ận đượ ừc t ngân hàng qua m t kênh bộ ảo mật gửi tới. Việc các khách hàng qu n lý danh ả sách này cũng quyế ịt đ nh đ n đế ộ an toàn c a chính tài khoản khách hàng. Tuy ủ nhiên, khách hàng để ấ m t cũng là việc không tránh khỏi, n u bị ấế m t thì khách hàng có th xin c p l i danh sách mể ấ ạ ật khẩu mới và danh sách cũ sẽ không còn hiệu lực. Về ặ m t nguyên tắc, các mật khẩu cũ sẽ ầ g n như ngay lập tức mất tác dụng sau khi có thông báo từ khách hàng. Nhưng vẫn hoàn toàn có rủi ro nếu có kẻ ấ x u biết được danh sách này khi nó v n còn hi u lẫ ệ ực và th c hi n các ự ệ giao d ch trái phép.ị
Độ dài c a m t kh u phủ ậ ẩ ả ải đ m bảo sao cho nó có độ ả b o mật tương đối và nhưng không quá phứ ạc t p gây khó khăn khi người dùng nhập li u. Tuy ệ nhiên nếu mật khẩu quá ng n thì sắ ẽ ễ ị d b quay vòng trong thời gian ng n, ắ độ an toàn theo đó cũng giảm đi. Các thu t toán mã hóa l i luôn yêu cầu khóa mã ậ ạ hóa lại có mộ ột đ dài xác đ nh nào đó, và đị ộ dài khóa càng l n thì càng bớ ảo mật. Nếu sử ụ d ng mã hóa trực tiếp từ ậ m t khẩu thì độdài mật khẩu sẽquá dài,
71
không thuận tiện cho ngư i dùng. Do đó, thay vì mã hóa trờ ực tiếp, h ệthống s ẽ mã hóa d a trên khóa sinh ra tự ừ ậ m t kh u này kẩ ết hợp thêm PIN của khách hàng. Đ khóa có để ộ dài c nh, c n s dố đị ầ ử ụng một hàm băm với đầu vào là mật khẩu và PIN của khách hàng.
4.3.4 Ứng dụng của các khóa
Trong ph n này sầ ẽ giới thiệu cách trao đổ ải b n tin và giao thức mã hóa được dùng. Giao thức này được tách biệt cho giao dịch vấn tin số dư và giao dịch chuyển khoản.
a. Giao dịch vấn tin số dư
Trong giao dịch vấn tin số dư chỉ có một bản tin được gửi về ngân hàng.
Bản tin sẽ ảo gồm nộ b i dung đã được mã hóa m1 dùng mật khẩu mộ ần như t l trong ph n 4.3.1 và mấ ột số digest cho m1 được sinh bởi hàm Hash.
M1 : C − S : ESK[m1] [m, H 1]
M2 : S − C : EAccP [< balance >] or < Errormessage >] inplaintext[ .
• m1 gồm các thông tin là: m1 = [AccID || Transaction Type SQ || PIN]. ||
• ESK là thuật toán mã hóa dùng mật khẩu một lần.
• EAccP là thuật toán mã hóa dùng mật khẩu kết hợp của số tài khoản, số Salt, và PIN.
• H là hàm hash để tạo ra digest cho bản tin m1.
• SQ là số thứ tự của mật khẩu.
• Transaction Type là số chỉ ra loại giao dịch.
• AccID là số tài khoản khách hàng.
72
Vì bản tin trả lời từ ngân hàng m2 cũng được mã hóa dựa trên PIN và tài khoản khách hàng nên khi nhận được bản tin trả về, thiết bị sẽ tự động bật ứng dụng di động và yêu cầu người dùng điền thông tin tài khoản và PIN của mình để truy nhập nội dung bản tin.
b. Giao dịch chuyển khoản
Trong giao dịch chuyển khoản cũng chỉ có m t bảộ n tin được gửi về ngân hàng. Bản tin sẽ bao gồm nội dung đã được mã hóa m2 dùng mật khẩu một lần như trong phần 4.3.1 và một số digest cho m2 được sinh bởi hàm Hash.
M1 : C − S : ESK[m2] [m, H 2]
M2 : S − C : EAccP [< confirmation ] or < Errormessage >] inplaintext > [ .
• m2gồm các thông tin là:
m2 = [AccID||DestinationAccID||Payload||Transaction Type || SQ ||
PIN].
• ESK là thuật toán mã hóa dùng mật khẩu một lần.
• EAccP là thuật toán mã hóa dùng mật khẩu kết hợp của số tài khoản, số Salt, và PIN.
• H là hàm hash để tạo ra digest cho bản tin m2.
• Phần payload (tải tin) là phần dữ liệu đặc trưng cho giao dịch, trong trường hợp này sẽ chứa số tiền giao dịch.
• Các trường AccID, SQ, PIN, Transation type có ý nghĩa như giao dịch kiểm tra số dư.
Mật khẩu nào đã được sử dụng thì coi như đã hết hiệu lực và hệ thống sẽ tự động từ chối nếu nó được dùng lại lần tiếp theo.
73
Phần phản hồi sẽ có nội dung thông báo xem giao dịch có thành công hay không và một số thông điệp khác như số dư tài khoản sau khi thực hiện giao dịch Bản tin trả lời từ ngân hàng M2 sẽ tự động bật ứng dụng di động yêu . cầu người dùng điền thông tin tài khoản và PIN của mình để truy nhập nội dung bản tin.
4.3.5 Tạo và gửi bản tin bảo mật
Các thông tin bảo mậ ủt c a ngư i dùng đườ ợ ức ng dụng di động trên máy di động thu th p. Các thông tin này bao gậ ồm số tài khoản, số PIN, số ứ ự th t và mật kh u dùng mẩ ột lần. Các thông tin này dùng để ạ t o ra b n tin SMS bả ảo mật gửi tới máy chủ. Đ đảm bảo tính toàn vẹn của bản tin tại phía nhận, ể người ta dùng digest của bản tin. Quá trình tạo ra digest di n ra c phía ng ễ ở ả ứ dụng người dùng và phía ngân hàng theo cùng một thuật toán. Digest bao gồm các thông tin là < Mật khẩu><PIN >< Loại giao dịch> và < Tải tin giao dịch>. Để duy trì tính toàn vẹn của bản tin thì các trường dùng để tính toán tính toàn vẹn đều phải được mã hóa để đảm bảo khi giao dịch bị chặn thì kẻ tấn công không thể tạo ra được một số digest khác. Kiểm tra tính toàn vẹn sẽ thất bại nếu bản tin gốc bị biến đổi.
Ngoài ra để máy chủ có thể xác nhận được chủ tài khoản thì một số thông tin nhận dạng chi tiết lại không được phép mã hóa. Việc lựa chọn này hoàn toàn phụ thuộc vào người phát triển. Thuật toán mã hóa đối xứng sẽ dùng mật khẩu một lần mà cả người dùng và ngân hàng đều biết. Mật khẩu dùng để tạo ra khóa mã hóa.
Khi kết thúc quá trình bảo mật nội dung, bản tin SMS sẽ được gửi đến ngân hàng qua mạng GSM như một bản tin thông thường với số thuê bao nhận là số nhận dạng máy chủ ngân hàng. Để có thể nhận được các bản tin này, ngân hàng phải đăng kí một đầu số với SMSC của mạng di động hoặc
74
thông qua một SMS gateway đứng giữa. Việc này hoàn toàn giống với các dịch vụ cung cấp nội dung khác đang được sử dụng.
Máy chủ khi nhận được bản tin từ mạng GSM sẽ giải mã chúng dựa trên cấu trúc bản tin đã mô tả ở trên. Các bit mang thông tin phiên bản sẽ được kiểm tra để xác định xem bản tin có phù hợp với giao thức SMS bảo mật không.
Phía máy chủ sẽ đọc và kiểm tra thông tin nhận dạng tài khoản xem có tồn tại trong CSDL hay chưa. Sau khi vượt qua các bước kiểm tra trên, máy chủ sẽ tìm mật khẩu một lần đã lưu sẵn trong CSDL hoặc sinh lại dựa trên thuật toán đã dùng trong trường hợp không lưu trữ. Mật khẩu này sau đó lại được đưa qua một hàm băm như đã dùng phía ứng dụng di động để sinh ra khóa giải mã để giải mã bản tin bảo mật nhận được.
Khi bản tin đã được giải mã thành công, mật khẩu một lần sẽ bị hủy và bộ đếm số thứ tự cũng tăng. Máy chủ đọc các thông tin đã được bảo mật cần thiết cho tính toán digest của bản tin. Máy chủ sẽ dùng một thuật toán tương tự như thuật toán dùng ở ứng dụng di động để tính toán digest. Sau đó hai số digest sẽ được so sánh với nhau để đảm bảo tính toàn vẹn của bản tin. Cuối cùng máy chủ đọc PIN của chủ tài khoản từ CSDL và so sánh với PIN được gửi kèm trong bản tin. Nếu tất cả các bước kiểm tra trên thỏa mãn thì giao dịch mà người dùng yêu cầu sẽ được thực hiện.