3.2.1. ProVerif
ProVerif là một công cụ xác minh giao thức mật mã nổi tiếng. ProVerif được thiết kế để phân tích các thuộc tính bí mật và xác thực. Các thuộc tính như quyền riêng tư, truy xuất nguồn gốc, khả năng xác minh cũng được sử dụng bởi ProVerif [5].
3.2.2. Mô hình giao thức
Mô hình gồm ba phần chính : khai báo, xử lý quy mô lớn và xử lý chính. Đối với HN và SN gồm một cặp khóa công khai và riêng tư. Đầu tiên, cặp khóa được sử dụng để mã hóa và giải mã thông điệp, sau đó cặp khóa được dùng để ký vào thông điệp và xác minh. Lưu ý rằng giao thức được đề xuất không trực tiếp sử dụng chữ ký số trong các chuỗi thông điệp của nó. Điều này được ngầm hiểu bởi các bên tham gia khi giao dịch đã được đăng ký trong Blockchain. Đặc biệt hơn, điều này được thực hiện khi một trong hai SN đăng ký yêu cầu xác thực hoặc HN đăng ký yêu cầu phản hồi [5].
3.2.2.1. Khai báo
Phần khai báo gồm ba phần : phần dành cho loại người dùng xác định, phần định nghĩa các đối tượng, nơi phương thức khởi tạo đã được xác định. Trong phần đầu tiên, privateKey và publicKey chỉ ra cặp khóa riêng tư và công khai được sử dụng
47
cho mã hóa bất đối xứng và chữ ký số. Trong khi Key và UEKey là những loại được sử dụng cho khóa mã hóa đối xứng. Trong phần hai, hai câu lệnh đầu tiên khai báo một số kênh giao tiếp : airChannel và bcChannel, được sử dụng để lập mô hình kênh giữa UE và SN và kênh giữa SN và HN tương ứng. Khái niệm về câu lệnh miễn phí trong ProVerif cũng giống như trong các ngôn ngữ lập trình. Định nghĩa đối tượng được kết thúc bằng phương pháp truy cập xác định bởi từ khóa "công khai " hoặc " riêng tư ". Các đối tượng mà không bị kẻ tấn công biết phải được khai báo riêng tư, trong khi những cái mà kẻ tấn công biết sẽ được khai báo công khai. Theo mặc định, phương thức truy cập là công khai (ví dụ : khi nó khai báo không rõ ràng thì công cụ sẽ coi đó là công khai).
Sự thể hiện của câu lệnh miễn phí với phương thức truy cập công khai trong định nghĩa của airChannel và bcChannel chỉ ra rằng cả hai kênh đều được biết bởi kẻ tấn công. Định nghĩa này phản ánh giả định thực tế về kênh liên lạc giữa SN và HN thì được cung cấp bởi các khối Blockchain công khai. Khi đó trong mỗi chuỗi khối công cộng muốn tham gia vào mạng lưới Blockchain và hoạt động như một nút đầy đủ (full node) và do đó có quyền truy nhập tới dữ liệu giao dịch cũng như các chức năng của hợp đồng thông minh.
Các đối tượng SUPI, K, 𝐾𝑆𝐸𝐴𝐹, 𝑅2 và 𝑅3 tương ứng biểu thị mã định danh duy nhất USIM, khóa nội bộ USIM, khóa phiên, số ngẫu nhiên HN và SN. Các từ khóa [private] trong định nghĩa ngụ ý rằng mỗi từ khóa là riêng tư và kẻ tấn công không thể truy nhập.
* Thuật toán 1 : Định nghĩa loại, đối tượng và hàm chức năng
type UEKey.
type Key.
type publicKey.
type privateKey.
48
free airChannel:channel. (∗Public∗)
free SUPI:bitstring [private].
free K:UEKey [private].
free 𝐾𝑆𝐸𝐴𝐹:bitstring [private].
free 𝑅3:bitstring [private].
free 𝑅2:bitstring [private].
fun hash(bitstring):bitstring.
fun mKey (bitstring): Key.
fun pk (privateKey): publicKey.
fun pkiEnc (bitstring, publicKey): bitstring.
reduc forall m: bitstring, k: privateKey; pkiDec (pkiEnc (m, pk (k)), k) = m.
fun symEnc (bitstring, Key): bitstring.
reduc forall m: bitstring, k: Key; symDec (symEnc (m, k), k) = m.
fun sign (bitstring, privateKey): bitstring.
reduc forall m:bitstring, k: privateKey; checksign(sign(m, k), pk (k)) = m.
fun decode(bitstring): bitstring.
fun 𝑓1 (UEKey, bitstring, bitstring): bitstring.
fun challenge(UEKey, bitstring, bitstring): bitstring.
fun keyseed(UEKey, bitstring, bitstring): bitstring.
Phần thứ ba định nghĩa các ký hiệu chức năng bao gồm cả hàm tạo và hàm hủy. Trong ProVerif, mỗi hàm tạo xây dựng các điều khoản bắt buộc để mô hình hóa từng phần nguyên thủy của giao thức mật mã. Trong giao thức đề xuất, hash, symEnc,
symDec, pkiEnc, pkiDec, sign và getPK là các hàm tạo, tương ứng trong mô hình là các hàm chức năng mật mã, mã hóa đối xứng, giải mã đối xứng, mã hóa khóa công khai, chữ ký số và trả về khóa công khai của khóa bí mật.
49
Trong giao thức dựa trên Blockchain, pkiDec, symDec và check_sign là hàm hủy, tương ứng trong mô hình là giải mã khóa công khai, giải mã khóa đối xứng và thuật toán xác minh chữ ký.
3.2.2.2. Xử lý quy mô lớn
Thay vì mã hóa giao thức trong một quy trình chính duy nhất, giao thức AKA dựa trên Blockchain sử dụng quy trình phụ để khai báo các tương tác giữa các bên tham gia. Giao thức có ba thành phần tham gia, ngoài quá trình xử lý chính, còn có ba quá trình xử lý quy mô lớn được định nghĩa là : SN, UE và HN. Mỗi quá trình nhận diện hoạt động của thành phần tham gia tương ứng với các sự kiện đã xảy ra.
Trong mô hình giao thức AKA dựa trên Blockchain, các quy trình này tương ứng chính xác với giao thức được đưa ra trong hình 3.3 với sự khác biệt nhỏ là lược bỏ một số chi tiết không cần thiết. Thay vì mô hình hóa chuỗi khối hoặc hợp đồng thông minh như một quá trình xử lý quy mô lớn, chúng được mô hình hóa bởi kênh giao tiếp bcChannel.
50
Hình 3. 3: Luồng thông báo của giao thức
* Thuật toán 2 : Quá trình xử lý tại SN
let SN(𝐼𝐷𝑆𝑁 :bitstring, 𝐼𝐷𝐻𝑁 :bitstring, 𝑝𝑘𝐻𝑁 : publicKey,
𝑝𝑘𝑆𝑁 : publicKey, 𝑠𝑘𝑆𝑁 : privateKey) =
new 𝑅1:bitstring;
event SNSendReqToUE;
out(airChannel, (𝑅1, 𝐼𝐷𝑆𝑁 ));
in(airChannel, SUCI:bitstring);
let recv_𝑖𝑑𝐻𝑁 = decode(SUCI) in
if recv_𝑖𝑑𝐻𝑁 = 𝑖𝑑𝐻𝑁 then event SNRecvUERes(SUCI);
let req_id = hash((𝐼𝐷𝐻𝑁, 𝑅1, 𝐼𝐷𝑆𝑁, SUCI)) in
51
event SNSendReqToHN(req_id);
out(bcChannel, (req_id, 𝑆𝑖𝑔𝑛𝐻𝑁, SUCI));
in(bcChannel, (𝐸𝐾𝐶:bitstring, xMac:bitstring,
hxRes:bitstring, 𝑆𝑖𝑔𝑛𝐻𝑁 : bitstring, res_id: bitstring,
HN_R:bitstring));
let (=𝑝𝑘𝐻𝑁 , veri_req_id:bitstring, veri_res_id:bitstring) =
checksign(SignHN , 𝑝𝑘𝐻𝑁 ) in
if (veri_res_id = res_id) then if (veri_req_id = req_id)
then event SNRecvHNRes(𝑆𝑖𝑔𝑛𝐻𝑁 );
event SNSendReq2ToUE(xMac);
out(airChannel, (xMac, HN_R));
in(airChannel, Res:bitstring);
if hxRes = Res then event SNRecvUERes2;
let EK = pkiDec (𝐸𝐾𝐶, 𝑠𝑘𝑆𝑁 ) in
let session_info = symDec (EK, mKey (Res)) in
let sn_𝐾𝑆𝐸𝐴𝐹 = decode(session_info) in
let sn_SUPI = decode(session_info).
Quá trình xử lý tại SN được thể hiện trong thuật toán 2. SN bắt đầu giao thức bằng cách chọn một số ngẫu nhiên 𝑅1 và đặt cặp (𝑅1, 𝐼𝐷𝑆𝑁) trên giao diện airChannel
chờ phản hồi từ người dùng. Khi nhận được phản hồi từ UE, SN tính req_id bằng cách sử dụng hàm băm và 𝑆𝑖𝑔𝑛𝑆𝑁 bởi chữ ký số. Sau đó, SN đặt req_id, 𝑆𝑖𝑔𝑛𝑆𝑁 và
SUPI trên giao diện bcChannel và đợi phản hồi từ HN.
Khi nhận được phản hồi của HN, SN chọn (xMac, HN_R) từ thông điệp và đặt chúng trên giao diện airChannel, chờ phản hồi từ người dùng. Khi nhận được phản hồi Res từ người dùng, SN so sánh Res với hxRes nhận được từ HN. Trong trường hợp trùng khớp, xác thực được chấp nhận và theo đó SN có thể truy xuất 𝐾𝑆𝐸𝐴𝐹 và
52
Tương tự, các quy trình UE và HN được giải thích tương ứng trong thuật toán 3 và thuật toán 4. Quá trình xử lý chính là điểm bắt đầu của giao thức, nó khởi tạo giao thức bằng cách thiết lập khóa hữu hình, các kênh giao tiếp sau đó gọi các bên tham gia quá trình xử lý.
* Thuật toán 3 : Quá trình xử lý tại người dùng
let UE(𝐼𝐷𝐻𝑁 :bitstring, 𝑝𝑘𝐻𝑁 : publicKey, K: UEKey,
SUPI:bitstring)=
in(airChannel,( 𝑅1:bitstring, 𝐼𝐷𝑆𝑁 :bitstring));
event UERecvSNReq(𝐼𝐷𝑆𝑁 ); (∗new 𝑅2: bitstring;∗)
let UI = pkiEnc ((SUPI, 𝑅1, 𝑅2, 𝐼𝐷𝑆𝑁 ), 𝑝𝑘𝐻𝑁) in
let SUCI = (UI, 𝐼𝐷𝐻𝑁 ) in
event UESendResToSN(SUCI);
out(airChannel, SUCI);
in(airChannel,(xMac:bitstring, HN_R:bitstring));
let ue_𝑅3 D symDec (HN_R, mKey (𝑅2)) in
let O = 𝑓1 (K, 𝑅1,( 𝑅2, 𝑅3)) in
let Mac = 𝑓1 (K, O, 𝐼𝐷𝑆𝑁 ) in
if Mac = xMac then event UERecvSNReq2(xMac);
let Res = challenge(K,O, 𝐼𝐷𝑆𝑁 ) in
let ue_𝐾𝑆𝐸𝐴𝐹 = keyseed(K,O, 𝐼𝐷𝑆𝑁 ) in
event UESendRes2ToSN(Res);
out(airChannel,Res).
* Thuật toán 4: Quá trình xử lý tại HN
let HN(𝐼𝐷𝐻𝑁 :bitstring, 𝐼𝐷𝑆𝑁 :bitstring, 𝑝𝑘𝐻𝑁 : publicKey,
𝑠𝑘𝐻𝑁 : privateKey, 𝑝𝑘𝑆𝑁 :publicKey,K: UEKey)=
in (bcChannel, (req_id: bitstring, 𝑠𝑖𝑔𝑛𝑆𝑁 : bitstring, SUCI:bitstring));
let (=𝑝𝑘𝑆𝑁 , veri_req_id:bitstring) = checksign(𝑠𝑖𝑔𝑛𝑆𝑁 , 𝑝𝑘𝑆𝑁 ) in