BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

BÁO CÁO BÀI TẬP

ĐỀ TÀI: TÌM HIỂU VÀ NGHIÊN CỨU MÃ QR CODE VÀ XÂY

DỰNG CHƯƠNG TRÌNH MÔ PHỎNG QUÁ TRÌNH SỬ DỤNG
QR CODE TRONG GIAO DỊCH

Ngành: An toàn thông tin

Sinh viên thực hiện:

Nguyễn Thế Long - AT170233
Nguyễn Quang Huy - AT170228
Triệu Đức Vinh - AT170257

Người hướng dẫn:

TS. Lê Quang Huy
Khoa ATTT - Học viện KTMM

Hà Nội - 2024
 MỤC LỤC

Mục lục..................................................................................................................i
Danh mục kí hiệu và viết tắt.............................................................................iii
Danh mục hình vẽ................................................................................................v
Danh mục bảng..................................................................................................vii
Lời nói đầu........................................................................................................viii
Chương 1. cơ sở lý thuyết...................................................................................1
1.1. Tổng quan Blockchain...............................................................................1
1.1.1. Khái niệm............................................................................................1
1.1.2. Một số vấn đề thách thức với công nghệ Blockchain........................11
1.1.3. Ứng dụng...........................................................................................16
1.1.4. Phân loại...........................................................................................17
1.2. Tổng quan danh tính điện tử....................................................................20
1.2.1. Định nghĩa.........................................................................................20
1.2.2. Quản lý định danh.............................................................................22
1.2.3. Các mô hình quản lý định danh........................................................24
Chương 2. Mô hình định danh số tự chủ........................................................28
2.1. Mô hình Self-Sovereign Identity..............................................................28
2.1.1. Các yếu tố cấu thành.........................................................................28
2.1.2. Tự chủ danh tính dựa trên Blockchain..............................................29
2.1.3. Kịch bản lý tưởng..............................................................................30
2.2. Nền tảng đề xuất Hyperledger..................................................................37
2.2.1. Tổng quan Hyperledger....................................................................37
2.3. Hyperledger Indy......................................................................................39
Chương 3. Xây dựng hệ thống ứng dụng công nghệ Blockchain trong bài
toán Quản lý Định danh điện tử.......................................................................50
3.1. Mục tiêu xây dựng....................................................................................50
3.2. Kịch bản thử nghiệm...............................................................................53
3.2.1.Chuẩn bị.............................................................................................53
3.2.2.Tổng quan kịch bản............................................................................55
3.2.3.Đặc tả chức năng...............................................................................57
3.3. Triển khai và cài đặt hệ thống giả lập......................................................53
3.3.1.Cấu hình nội dung tệp cài đặt............................................................53
3.3.2. Khởi động hệ thống...........................................................................55
3.3.3. Tiến hành thử nghiệm........................................................................57
3.4. Kết luận....................................................................................................64

i
KẾT LUẬN........................................................................................................68
TÀI LIỆU THAM KHẢO................................................................................69

DANH MỤC KÍ HIỆU VÀ VIẾT TẮT

Ký hiệu chữ
STT Từ tiếng Anh Nghĩa tiếng Việt
viết tắt

1 AI Artificielle Intelligence Trí tuệ nhân tạo

Giao diện lập trình ứng

2 API Application Programming Interface
dụng

3 AR Augmented Reality Thực tế ảo tăng cường

Khả năng chịu lỗi

4 BFT Byzantine Fault Tolerance
Bazantine

Đồ thị có hướng không

5 DAG Directed Acyclic Graph
tuần hoàn

6 DApp Decentralised Application Ứng dụng phân tán

7 DeFi Decentralised Finance Tài chính phân tán

8 DID Decentralised Identity Danh tính phân tán

Công nghệ Sổ cái Phân

9 DLT Distributed Ledger Technology
tán

Elliptic Curve Digital Signature Thuật toán chữ ký số

10 ECDSA
Algorithm đường cong Elliptic

11 GPU Graphic Processing Unit Bộ xử lý đồ hoạ

12 ID Identity Danh tính

13 IoT Internet of Things Internet vạn vật

International Telecommunication Liên minh Viễn thông

14 ITU
Union Quốc tế

15 P2P Peer-to-peer Ngang hàng

16 PoA Proof of Authority Bằng chứng uỷ quyền

ii
 Bằng chứng thời gian
17 PoET Proof of Elapsed Time
trôi qua

18 PoS Proof of Stake Bằng chứng cổ phần

19 PoW Proof of Work Bằng chứng công việc

20 QR Quick Response Phản hồi nhanh

Bằng chứng công việc

21 RPoW Reusable Proof of Work
khả tái sử dụng

Bộ công cụ phát triển

22 SDK Software Development Kit
phần mềm

Phần mở rộng Bảo vệ

23 SGX Software Guard Extension
Phần mềm

24 SSID Self-Sovereign Identity Tự chủ danh tính

25 SSO Single Sign-On Đăng nhập một lần

Môi trường thực thi

26 TEE Trusted Execution Environment
đáng tin cậy

27 TX Transaction Giao dịch

Đầu ra giao dịch chưa

28 UTXO Unspent Transaction Output
sử dụng

29 VR Virtual Reality Thực tế ảo

iii
 DANH MỤC HÌNH VẼ

Hình 1-1: Khối trong chuỗi khối, cây Merkle trong một khối..............................4
Hình 1-2: Địa chỉ Ethereum - Source: medium.com.............................................5
Hình 1-3: Hệ thống mạng ngang hàng..................................................................6
Hình 1-4: Mô hình hoạt động của một Blockchain công khai............................11
Hình 1-5: Phân nhánh trong Blockchain.............................................................12
Hình 1-6: Vòng đời định danh điện tử................................................................21
Hình 1-7: Mô hình quản lý định danh ứng với từng nhà cung cấp dịch vụ.........23
Hình 1-8: Mô hình quản lý định danh tập trung..................................................23
Hình 2-1: Các tác nhân trong mô hình tự chủ danh tính.....................................30
Hình 2-2: Lược đồ hoạt động của mô hình tự chủ danh tính..............................30
Hình 2-3: Tam giác Blockchain - Blockchain Trilemma....................................38
Hình 2-4: Hệ sinh thái Hyperledger....................................................................39
Hình 2-5: Cú pháp DID.......................................................................................40
Hình 2-6: Mô hình xác thực danh tính truyền thống...........................................41
Hình 2-7: Mô hình xác thực danh tính sử dụng tự chủ danh tính........................41
Hình 3-1: Tương tác giữa các thực thể................................................................50
Hình 3-2: Giao diện của Alice.............................................................................51
Hình 3-3: Thông tin khởi tạo các node................................................................52
Hình 3-4: Mẫu đăng ký chứng chỉ.......................................................................54
Hình 3-5: Giao diện quản lý của đại học Faber...................................................54
Hình 3-6: Faber gửi yêu cầu kết nối đến Alice....................................................55
Hình 3-7: Thư yêu cầu được kết nối với Alice gửi từ Faber...............................55
Hình 3-8: Alice kết nối thành công với Faber.....................................................56
Hình 3-9: Faber cấp chứng chỉ học thuật cho Alice............................................56
Hình 3-10: Alice chấp nhận chứng chỉ học thuật................................................57
Hình 3-11: Thông tin chứng chỉ học thuật của Alice..........................................64
Hình 3-12: Tập đoàn ACME chấp nhận yêu cầu kết nối từ Alice.......................64

iv
Hình 3-13: Tập đoàn ACME sao chép mẫu yêu cầu xem chứng chỉ từ đại học
Faber....................................................................................................................65
Hình 3-14: ACME gửi yêu cầu xem chứng chỉ của Alice...................................65
Hình 3-15: Alice cho phép tập đoàn ACME xem chứng chỉ...............................66
Hình 3-16: ACME đã có thể xem chứng chỉ học thuật của Alice.......................66

v
 DANH MỤC BẢNG

Bảng 2-1: Bảng yếu tố cấu thành mô hình tự chủ danh tính...............................28
Bảng 3-1: Trường dữ liệu của một giao dịch......................................................57

vi
 LỜI NÓI ĐẦU

Trong thời đại kỹ thuật số hiện nay, định danh tự chủ đã trở thành một
vấn đề quan trọng đối với việc bảo vệ thông tin cá nhân của mỗi cá nhân khi
tham gia vào các hoạt động trực tuyến. Điều này càng trở nên cấp thiết hơn
trong bối cảnh mà các cuộc tấn công mạng và vi phạm dữ liệu cá nhân ngày
càng trở nên phổ biến. Blockchain đã và đang chứng tỏ đây là một yếu tố cho
công cuộc chuyển đổi số cũng như xây dựng nền tảng công nghệ thông tin.
Chính nhờ những đặc điểm của công nghệ Blockchain: minh bạch, bất biến, bảo
mật; Blockchain dần trở thành xu thế cho công nghệ hiện nay. Nhiều bài toán
đặt ra trong quá khứ như việc quản lý bản quyền số, quản lý hồ sơ y tế, truy xuất
nguồn gốc nông sản… từng gặp nhiều khó khăn vì sự tập trung hoá trong quá
trình phát triển, nay hoàn toàn có thể giải quyết bằng công nghệ Blockchain nhờ
tính chất minh bạch và bất biến của mình.
Blockchain là một công nghệ mới với tiềm năng lớn. Với khả năng bảo vệ
dữ liệu an toàn, minh bạch nội dung cũng như không thể thay đổi, Blockchain
cho thấy khả năng sử dụng làm nền tảng cho giải pháp quản lý định danh điện
tử, giúp những Nhà cung cấp dịch vụ và Nhà phát hành danh tính dễ dàng tiếp
cận với người dùng, xử lý bài toán (phát hành và kiểm tra danh tính) một cách
dễ dàng, minh bạch và có tính chính xác cao.
Hyperledger Indy là một nền tảng blockchain được thiết kế để hỗ trợ việc
định danh tự chủ và giải quyết vấn đề về tính bảo mật và quản lý thông tin cá
nhân. Bằng cách sử dụng các công nghệ tiên tiến, Hyperledger Indy cho phép
người dùng kiểm soát hoàn toàn các thông tin cá nhân của mình, đồng thời giúp
người dùng xác thực danh tính một cách an toàn và chính xác.
Trong báo cáo này, nhóm chúng em sẽ trình bày về nền tảng Hyperledger
Indy và các thành phần cơ bản của nó, đồng thời tìm hiểu cách triển khai mô
hình định danh tự chủ trên nền tảng này. Ngoài ra trong bài báo cáo cũng đưa ra
cái nhìn khái quát và nên tảng cơ sở lý thuyết để triển khai một hệ tống định
danh sử dụng Blockchain, cũng như so sánh các mô hình quản lý định danh đã
và đang được sử dụng trong thực tế để cho thấy sự hiệu quả và tiềm năng trong
việc sử dụng Hyperledger Indy để quản lý định danh tự chủ.

vii
 CHƯƠNG 1. TỔNG QUAN VỀ MÃ QRCODE
1.1. Tổng quan Blockchain

1.1.1. Khái niệm

1.1.1.1. Lịch sử ra đời
Mã QR (tạm dịch là mã đáp ứng nhanh) là một loại ma trận mã vạch( hay mã
vạch hai chiều) ban đầu được thiết kế cho nền công nghiệp ô tô Nhật Bản. Các
mã QR được sử dụng phổ biến nhất ở Nhật Bản và hiện là loại mã hai chiều
thông dụng nhất ở Nhật Bản. Gần đây, hệ thống mã QR đã trở nên phổ biến bên
ngoài ngành công nghiệp ô tô do khả năng đọc nhanh và dung lượng lưu trữ lớn
hơn so với tiêu chuẩn mã vạch UPC.

Hình ảnh mã QR Code

Một mã QR được đọc bởi một đầu đọc mã vạch, chẳng hạn như một máy
ảnh, một điện thoại di động, một điện thoại thông minh, hoặc một webcam, và
sử dụng thuật toán sửa lỗi Reed-Solomon.
Mã QR được phát minh tại Nhật Bản bởi công ty Denso Wave( công ty con
của Toyota) vào năm 1994 để theo dõi xe trong sản xuất.
Các mã QR nhỏ nhất là 21x21 pixel, và lớn nhất là 177x177. Các kích thước
được gọi là phiên bản. Kích thước 21x21 pixel là phiên bản 1, 25x25 là phiên
bản 2, và cứ tiếp tục như thế. Kích thước 177x177 là phiên bản 40.

1. Sử dụng

Ban đầu được thiết kế cho mục đích sử dụng công nghiệp, mã QR đã trở nên
phổ biến trong quảng cáo của người tiêu dùng. Điện thoại thông minh của người
dùng có thể cài đặt một ứng dụng với một máy quét QR-code có thể đọc được
một mã hiển thị và chuyển đổi nó vào một URL chỉ đến trang web của một công

1
ty, cửa hàng, hoặc sản phẩm liên quan đến mã cung cấp thông tin cụ thể bằng
trình duyệt web của điện thoại.
"In the shopping industry, knowing what causes the consumers to be
motivated when approaching products by the use of QR codes, advertisers and
marketers can use the behavior of scanning to get consumers to buy, causing it
to have the best impact on ad and marketing design" - Tolliver-Walker, Heidi
(2011). Kết quả là, mã QR đã trở thành một trọng tâm của quảng cáo chiến lược,
vì nó cung cấp truy cập nhanh và dễ dàng đến trang web của thương hiệu. Ngoài
việc tiện lợi cho người tiêu dùng, tầm quan trọng của điều này khả năng là nó
làm tăng tỷ lệ chuyển đổi (có nghĩa là, làm tăng cơ hội có thể liên lạc với các
quảng cáo sẽ chuyển đổi để bán), bằng cách đưa người xem đến trang web của
nhà quảng cáo ngay lập tức.
Mã QR lưu trữ địa chỉ và Uniform Resource Locators (URL) có thể xuất hiện
trên các tạp chí, trên các chữ ký, trên xe buýt, trên thẻ kinh doanh, hoặc trên hầu
hết các đối tượng cần sử dụng thông tin. Người sử dụng với một máy ảnh điện
thoại được trang bị một ứng dụng đọc chính xác có thể quét hình ảnh của mã QR
để hiển thị văn bản, thông tin liên lạc, kết nối với một mạng không dây , hoặc
mở một trang web trong trình duyệt của điện thoại. Mã QR cũng có thể nối tiếp
đến một vị trí nơi mà mã đã được quét. Hoặc các ứng dụng quét mã QR truy
xuất thông tin địa lý bằng cách sử dụng GPS và tế bào tam giác tháp (aGPS)
hoặc URL được mã hóa trong mã QR chính nó được liên kết với một vị trí.
1.1.1.2. Đặc điểm của QR Code
1. So sánh QR code và BarCode
QR Code chứa đựng thông tin một địa chỉ web, thời gian diễn ra một sự kiện,
thông tin liên hệ địa chỉ email, tin nhắn SMS, nội dung ký tự văn bản hay thậm
chí là thông tin định vị vị trí địa lý. Tùy thuộc thiết bị đọc mã QR mà bạn dùng
khi quét, nó sẽ dẫn bạn tới một trang web, gọi đến một số điện thoại, xem một
tin nhắn...
QR code cũng tương tự mã vạch truyền thống tuy nhiên điểm khác nhau giữa
QR code và mã vạch truyền thống là lượng dữ liệu chúng nắm giữ hay chia sẻ.
Các mã vạch truyền thống có các đường vạch thẳng dài một chiều và chỉ có
thể lưu giữ 20 số chữ số, trong khi QR code hai chiều có thể lưu giữ thông tin
hàng ngàn ký tự chữ số. QR code nắm giữ nhiều thông tin hơn và tính chất dễ
dùng sẽ giúp ích rất nhiều cho các doanh nghiệp vừa và nhỏ.
2. Ưu điểm

 Mã vạch QR là một loại mã vạch hai chiều có nhiều tính năng ưu việt
do Công ty Denso của Nhật Bản phát minh. Mã vạch QR có khả năng
mã hóa nhiều thông tin, giải mã nhanh, khả năng sửa lỗi cao(có thể đọc
được mã bị mờ hoặc mất đi một phần) và có thể mã hóa được ký tự

2
 Kanji và chữ tiếng Việt. Thông qua việc tích hợp vào các thiết bị điện
thoại di động, mã QR đang được các công ty Nhật Bản phát triển thành
các giải pháp thông minh cho thương mại qua di động…
 Một mã QR có thể chứa đựng thông tin một địa chỉ web (URL), thời
gian diễn ra một sự kiện, thông tin liên hệ (như vCard), địa chỉ email,
tin nhắn SMS, nội dung ký tự văn bản hay thậm chí là thông tin định vị
vị trí địa lý. Tùy thuộc thiết bị đọc mã QR mà bạn dùng khi quét, nó sẽ
dẫn bạn tới một trang web, gọi đến một số điện thoại, xem một tin
nhắn…

3. Nhược điểm
Những ứng dụng trong tương lai dành cho mã vạch QR code là rất lớn,
nhưng mã vạch này cũng có những hạn chế nhất định như sau:

 QR code đòi hỏi phải có phần mềm đọc mã trên điện thoại, và nếu mã
này xuất hiện ngoài trời như trên billboard, bến xe… có thể những
chướng ngại vật khác sẽ hạn chế khả năng nhận dạng của máy. Bạn
phải có smart phone tích hợp camera mới đọc được mã.
 QR code cũng không có tính lan truyền (viral) như hình thức nhắn tin
SMS…
 Hơn nữa, tuy QR code cực kỳ phổ biến tại Nhật Bản, song nhìn chung
loại mã này vẫn còn khá mới mẻ. Thông thường doanh nghiệp phải
giải thích và hướng dẫn khách hàng cách sử dụng.

4. Khả năng lưu trữ của QR code

Số lượng dữ liệu có thể được lưu trữ trong các biểu tượng QR code phụ
thuộc vào kiểu dữ liệu (hình thức hoặc tập ký tự đầu vào), phiên bản (1,…,40,
mô tả kích thước của QR Code), và mức độ sửa lỗi. Khả năng lưu trữ tối đa cho
40-L symbols (ở phiên bản 40, mức sửa lỗi là L):

Ký tự khả dụng,
Chế độ đầu vào Ký tự tối đa Bit/char
bộ mã hoá mặc định

3
 0, 1, 2, 3, 4, 5,
Số đơn thuần 7,089 3⅓
6, 7, 8, 9

0–9, A–Z (chỉ

Chữ và số 4,296 5½ chữ hoa), cách, $, %,
*, +, -, ., /, :

Số nhị phân 2953 8 ISO 8859-1

Kanji/Kana 1817 13 Shift JIS X 0208

Phiên bản 4 (33x33) :

Phiên bản 1(21x21) : Phiên bản 2(25x25) : Phiên bản 3(29x29) :
“Ver1” “Version2” “Version 4 QR code,
“Version 3 QR code”
up to 50 char”

4
 5. Khả năng sửa lỗi
Mức L: 7% số từ mã (codeword) có thể được phục hồi.
Mức M: 15% số từ mã có thể được phục hồi.
Mức Q: 25% số từ mã có thể được phục hồi.
Mức H: 30% số từ mã có thể được phục hồi.

CHƯƠNG 2. MÔ ĐỊNH DANH SỐ TỰ CHỦ

2.1. Mô hình Self-Sovereign Identity (SSI- Danh tính tự chủ)

2.1.1. Các yếu tố cấu thành

Christopher Allen đã đề xuất 10 yếu tố cấu thành để một mô hình quản lý
có thể được coi là tự chủ danh tính SSID. 10 yếu tố này có thể chia thành ba
nhóm: bảo mật (Security), kiểm soát (Controllability) và di động (Portability):

Security Controllability Portability

The identity information the user must be in the user must be able to
must be kept secure control of who can see use their identity data
and access their data whenever they want and
not be tied to a single
provider

Protection Existence Interoperability

Persistence Persistence Transparency

Minimisation Control Access

Consent

Bảng 2-1: Bảng yếu tố cấu thành mô hình tự chủ danh tính
Existence(Sự tồn tại): Người dùng phải tồn tại độc lập, và danh tính chỉ
để tham chiếu đến họ.
Control(Kiểm soát): Người dùng hoàn toàn kiểm soát danh tính của họ
như chia sẻ, cập nhật hay che giấu chúng. Nói cách khác, người dùng tự chủ
trong cách danh tính của mình được sử dụng.
Access(Truy cập): Người dùng là người duy nhất và có thể dễ dàng truy
cập vào toàn bộ dữ liệu gắn với định danh của họ. Tuy nhiên điều này không

5
đồng nghĩa với việc người dùng nắm quyền thay đổi thông tin của họ, nhưng họ
có thể biết bất cứ thay đổi nào tiềm tảng rủi ro cho họ.
Transparency(Minh bạch): Cách danh tính của người dùng được sử
dụng cần được công khai, minh bạch. Yếu tố này đảm bảo người dùng có thể
giám sát cách danh tính của họ được lưu trữ và sử dụng. Hệ thống và thuật toán
phải mở, không chỉ về chức năng mà cả cách quản lý, cập nhật, giúp người dùng
tự bảo vệ khỏi những rủi ro tiềm tàng.
Persistence(Bền bỉ): Danh tính cần tồn tại lâu dài, nên tồn tại mãi mãi trừ
khi người dùng không muốn giữ nữa.
Portability(Di động): Thông tin cần có tính di động. Danh tính không
nên được duy nhất một tổ chức nắm giữ, dù cho tổ chức này đáng tin cậy đến
đâu. Tổ chức đó có thể không tồn tại lâu dài. Một định danh có tính di động đảm
bảo rằng định danh đó tồn tại lâu dài và người dùng có khả năng kiểm soát.
Interoperability(Tương tác): Khả năng tương tác. Danh tính phải có khả
năng sử dụng rộng rãi nhất. Danh tính sẽ có giá trị thấp nếu chỉ có tác dụng cho
phạm vị hẹp. Với sự phát triển của Internet, nhu cầu được kết nối với nhiều nhà
cung cấp dịch vụ và nhiều nền tảng ngày càng cao. Vì thế việc một định danh
được chấp nhận bởi nhiều nền tảng là điều thiết yếu.
Consent(Chấp thuận): Việc sử dụng danh tính của người dùng cần có sự
đồng thuận của họ. Hay nói cách khác, nếu muốn chia sẻ dữ liệu cần được chủ
của nó cho phép! Đa số các hệ sinh thái đa nền tảng hiện nay đều đảm bảo
Interoperability, một danh tính sẽ được chia sẻ trên nhiều nền tảng của hệ sinh
thái này. Tuy nhiên tất cả điều đó chỉ được thực hiện dựa trên sự đồng thuận của
người dùng. Ví dụ: khi một ứng dụng muốn kết nối đên tài khoản facebook sẽ
cần người dùng phê duyệt.
Minimalization(Tối thiểu hóa): Giới hạn tới mức tối thiểu lộ lọt thông
tin. Chỉ những thông tin cần thiết nên được chia sẻ, còn những thông tin khác
nên được bảo mật tránh những rủi ro tiềm tàng. Ví dụ: Một hệ thống cần tuổi
của người thì chỉ nên chia sẻ tuổi, không nên chứa nhiều thông tin hơn như ngày
sinh.
Protection(Bảo vệ): Quyền của người dùng cần đặt lên trên mọi thứ, cho
dù có đi ngược lại lợi ích của nhà cung cấp danh tính.

2.1.2. Tự chủ danh tính dựa trên Blockchain

Với Blockchain, SSID cho phép người dùng sở hữu và kiểm soát danh
tính của họ, trình danh tính khi cần thiết để những nhà cung cấp dịch vụ có thể
xác minh. Sổ cái phân tán giúp quá trình xác thực và uỷ quyền của nhà cung cấp

6
dịch vụ phi tập trung hoá, biến SSID tương tự như hợp đồng thông minh giữa
các nhà phát hành danh tính (Issuer), chủ sở hữu danh tính (Owner - người
dùng) và bên xác thực (Verifier). Những công nghệ Blockchain dựa trên kiến
trúc sổ cái phân tán DLT có thể coi là giải pháp lý tưởng đáp ứng 10 yêu cầu của
SSID.

Hình 2-1: Các tác nhân trong mô hình tự chủ danh tính

2.1.3. Kịch bản lý tưởng

Kịch bản dưới đây mô tả quá trình hoạt động của một hệ thống sử dụng
mô hình tự chủ danh tính.

Hình 2-2: Lược đồ hoạt động của mô hình tự chủ danh tính
Mô tả: John muốn thuê một chiếc xe để đi du lịch. Để thuê được xe thì
anh sẽ cần trình bày với dịch vụ cho thuê xe với những thông tin cá nhân như:
tuổi, bằng lái xe…
Các bước thực hiện như sau:

7
 Bước 1: John sử dụng ứng dụng Ví để đăng ký Mã định danh người dùng
(User DID) nhằm lưu trữ Danh tính cá nhân.
Bước 2: John kết nối với Issuer (Nhà phát hành), làm thủ tục để xin Bằng
lái xe điện tử.
Bước 3: Nhà phát hành cung cấp Bằng lái xe điện tử cho John và ký bằng
khoá bí mật của Mã định danh nhà phát hành (Issuer DID).
Bước 4: John nhận bằng lái xe đã ký, ký lại lần nữa với User DID và lưu
trữ ở thiết bị của mình (Ví).
Bước 5: John kết nối dịch vụ cho thuê xe (Verifier), chọn xe và yêu cầu
đặt xe.
Bước 6: John cung cấp một phần thông tin của Bằng lái xe điện tử đã
được cung cấp.
Bước 7: Dịch vụ cho thuê xe xác minh chữ ký của người dùng (User
DID) và của nhà phát hành (Issuer DID) để xác nhận John muốn thuê xe và
Bằng lái xe được phát hành của đúng công ty cung cấp.
Bước 8: Xác thực thành công, dịch vụ cho thuê xe cho John thuê xe.
Bằng cách này, John (Owner) có thể chứng minh mình đủ điều kiện thuê
xe mà không cần bước đăng ký với dịch vụ cho thuê xe. Và với Bằng lái xe điện
tử này, John có thể sử dụng cho nhiều dịch vụ khác nhau, chỉ cần cung cấp
những thông tin mà dịch vụ đó cần, tăng tính tiện dụng, bảo mật và tự chủ thông
tin.
2.2. Nền tảng Hyperledger

2.2.1. Tổng quan Hyperledger

Hyperledger là một dự án mã nguồn mở thuộc tổ chức Linux Foundation.
Hyperledger xây dựng một hệ sinh thái các giải pháp áp dụng công nghệ
Blockchain mà người dùng trên hệ sinh thái này có thể sử dụng nhằm giải quyết
các vấn đề trong ngành công nghiệp.
Mục đích của Linux Foundation là tạo ra một cộng đồng các nhà phát
triển làm việc trên các dự án mã nguồn mở, nhằm duy trì sự phát triển của các
dự án, trong đó, mã nguồn dự án luôn được nâng cấp, sửa đổi và phân phối lại.
Tư tưởng của Hyperledger là thế giới sẽ gồm nhiều chuỗi (private chain)
riêng biệt dành cho mỗi bối cảnh khác nhau. Mỗi doanh nghiệp sẽ có đặc trưng
riêng, vì thế các ứng dụng cho doanh nghiệp sẽ cần phát triển với các quy tắc
được cá nhân hoá.

8
 Dự án Hyperledger được triển khai từ năm 2015 với một số ít các nhà
phát triển. Những nhà phát triển này đến từ nhiều lĩnh vực khác nhau như khoa
học dữ liệu, sản xuất, ngân hàng… và họ có một mục tiêu chung, đó là làm
Blockchain trở thành công nghệ dễ tiếp cận hơn cả cho chính các nhà phát triển
lẫn các doanh nghiệp. Dự án được bắt đầu với các tương tác thử nghiệm giữa
ứng dụng và một mạng Blockchain an toàn.
Trong quá trình thử nghiệm các nhà phát triển nhận ra rằng với
Blockchain, khi các nút trong mạng cần xác thực giao dịch và thực hiện cơ chế
đồng thuận cùng lúc sẽ gây ảnh hưởng rất lớn đến hiệu năng thực hiện, dẫn đến
khả năng mở rộng quy mô (Scalability) bị hạn chế. Muốn đẩy nhanh hiệu suất
thì phải giảm tải quá trình xác thực và đồng thuận, tức là chúng ta phải hi sinh
yếu tố phi tập trung (Decentralization) hoặc tính bảo mật (Security).
Đây chính là ba vấn đề nổi trội của bất kỳ Blockchain nào, còn được gọi
là nghịch lý tam giác Blockchain - Blockchain Trilemma. Bài toán này chỉ ra
rằng một Blockchain chỉ có thể giải quyết 2/3 vấn đề của tam giác và phải hy
sinh yếu tố còn lại.

Hình 2-3: Tam giác Blockchain - Blockchain Trilemma

Ngoài ra, các giao dịch thực hiện trong doanh nghiệp cần đảm bảo tính
riêng tư, bảo mật (confidentiality), không nên được công bố công khai. Chẳng
hạn như giao dịch mua bán giữa các doanh nghiệp. Một doanh nghiệp khi bán
một sản phẩm cho nhiều đối tác khác nhau sẽ có các mức giá khác nhau, tuỳ
thuộc vào bối cảnh, mối quan hệ, số lượng mua bán giữa hai bên. Sử dụng một
Blockchain công khai sẽ công khai hoàn toàn các giao dịch, dễ khiến các bên
thứ ba khi nhìn vào giao dịch của hai thực thể trên sẽ có những đánh giá khác
nhau, gây mất niềm tin giữa các doanh nghiệp.
Chính vì thế, nhóm Hyperledger đưa ra ý tưởng phát triển một hệ sinh thái
các sản phẩm sử dụng chuỗi khối riêng tư (private blockchain). Private

9
Blockchain sẽ hi sinh một phần tính phi tập trung và bảo mật trong tam giác
Blockchain Trilemma để thúc đẩy thông lượng giao dịch - hiệu năng của
Blockchain. Ngoài ra Hyperledger cũng sẽ thiết lập mô hình Private Blockchain
mà ở đó, mỗi doanh nghiệp sẽ duy trì một chain khác nhau, khi cần kết nối sẽ
kết nối thông qua kênh (channel). Thông tin cần chia sẻ (ledger) sẽ được phân
phối tới toàn bộ các nút tham gia kênh này, các nút này thuộc về hai tổ chức
tham gia kết nối, giúp dữ liệu chỉ được chia sẻ trong nội bộ các nút tham gia,
chứ không phải công khai lên toàn thế giới.

Hình 2-4: Hệ sinh thái Hyperledger

2.3.Hyperledger Indy
2.3.1Khái niệm
Hyperldger Indy là một sổ cái phân tán, được xây dựng nhằm mục đích
định danh phi tập trung. Hyperledger Indy cung cấp các công cụ, thư viện và các
thành phần có thể tái sử dụng nhằm tạo, sử dụng các định danh số (digital
identities) một cách độc lập hoạt động trên các chuỗi khối hoặc sổ cái phân tán
khác để chúng có thể được vận hành trên các miền quản trị, ứng dụng.
2.3.2Mô hình tự chủ danh tính
Hyperledger Indy triển khai mô hình tự chủ danh tính (Self-Sovereign
Identity). Như đã đề cập ở phần II.1, mô hình này hoạt động cơ bản như sau:
Người dùng phải có khả năng kiểm soát danh tính của chính mình. Tự chủ
danh tính sẽ phải là định danh số tồn tại vĩnh viễn, có thể chia sẻ thông tin cho
bất kỳ cá nhân, tổ chức nào dưới quyết định của chính người dùng mà không
chịu sự quản lý của bất kỳ cơ quan tập trung nào, cũng như không thể bị lấy đi.

10
 2.3.3Danh tính phi tập trung
Danh tính phi tập trung (Decentralized Identify - DID) là danh tính của
một chủ thể, được quản lý tự chủ bởi chính chủ thế đó chứ không chịu sự quản
lý của các nhà cung cấp danh tính. Chính vì vậy DID được thiết kế cho phép các
cá nhân vào tổ chức tự sinh ra danh tính của mình tuỳ thuộc vào hệ thống sử
dụng. Các danh tính này cho phép các thực thể chứng minh quyền kiểm soát
danh tính bằng cách sử dụng các bằng chứng mật mã, chẳng hạn như dùng chữ
ký số.
Vì quá trình tạo và sử dụng DID hoàn toàn do bản thân thực thể quản lý,
cho nên mỗi thực thể có thể tạo rất nhiều DID khác nhau, tuỳ thuộc vào bối
cảnh, mối quan hệ tương tác, yêu cầu sử dụng của thực thể đó. Các danh tính có
thể sử dụng trong nhiều bối cảnh khác nhau, tương tác với nhiều hệ thống khác
nhau, cho phép người dùng có thể kiểm soát danh tính bằng cách chỉ cần tiết lộ
vừa đủ thông tin danh tính của mình khi cần thiết.
DID có cấu trúc tương tự cú pháp URN, được thể hiện dưới dạng chuỗi
gồm ba phần: Scheme, Method và Method-specific Identifier.

Hình 2-5: Cú pháp DID

Lưu ý rằng: mỗi thực thể có thể có nhiều DID khác nhau, tuỳ thuộc vào
mối quan hệ, bối cảnh sử dụng và số lượng thông tin muốn chia sẻ. Ta có DID
khác nhau cho từng mối quan hệ khác nhau, và vì thế để quản lý bộ DID cá nhân
của mình, chúng ta cần một ứng dụng đại diện (software agent), có chức năng
như người quản lý các DID của mình.
2.3.4 Xác thực danh tính
Quá trình xác thực danh tính của mô hình truyền thống có thể mô tả như
sau:

11
 Hình 2-6: Mô hình xác thực danh tính truyền thống
Nhà phát hành danh tính sẽ phát hành danh tính cho người dùng - chẳng
hạn như Tổng cục Đường bộ Việt Nam sẽ cấp Bằng lái xe cho công dân Việt
Nam. Khi người dùng cần chứng minh danh tính bản thân cho bên yêu cầu danh
tính - ví dụ như cảnh sát giao thông - người dùng sẽ đưa tài liệu được cấp cho
bên yêu cầu danh tính - ở đây là bằng lái xe đã được cấp. Bên yêu cầu danh tính
thực hiện xác thực xem danh tính đó còn khả dụng và có hợp lệ hay không.
Ngoài ra, người dùng không thể chọn chỉ đưa một phần thông tin trong tài liệu,
mà phải đưa toàn bộ tài liệu cho bên yêu cầu danh tính - toàn bộ bằng lái xe.
Quá trình xác thực danh tính trong mô hình tự chủ danh tính được mô tả
như sau:

Hình 2-7: Mô hình xác thực danh tính sử dụng tự chủ danh tính

12
 Nhà phát hành danh tính đồng thời thực hiện hai việc: đăng ký bằng
chứng toàn vẹn thông tin về danh tính đã phát hành lên Blockchain, đồng thời
phát hành danh tính đó cho người dùng. Người dùng lưu trữ danh tính đó trong
ứng dụng của mình. Khi có yêu cầu từ bên xác thực danh tính, người dùng sẽ
trình bày một phần (hoặc toàn bộ) thông tin danh tính mình sở hữu cho bên xác
thực danh tính. Bên xác thực danh tính sau đó sẽ kiểm tra tính toàn vẹn thông tin
danh tính ở trên Blockchain nhằm đảm bảo danh tính này hợp lệ.

CHƯƠNG 3. XÂY DỰNG HỆ THỐNG ỨNG DỤNG CÔNG NGHỆ

BLOCKCHAIN TRONG BÀI TOÁN QUẢN LÝ ĐỊNH DANH ĐIỆN TỬ
3.1. Mục tiêu xây dựng
Mục tiêu xây dựng một hệ thống quản lý định danh như sau:
Hệ thống quản lý định xanh và xác thực điện tử cho phép các nhà phát
hành định danh cung cấp định danh điện tử, người dùng làm chủ toàn bộ danh
tính của chính họ, đồng thời cho phép các nhà cung cấp dịch vụ có thể xác thực
và giao dịch trực tuyến.
Hệ thống được xây dựng trên nền tảng công nghệ Blockchain đảm bảo
tính bảo mật và toàn vẹn dữ liệu. Ngoài ra với công nghệ sổ cái phân tán sẽ giúp
các nhà định danh (Issuer) và các nhà cung cấp dịch vụ (Verifier) dễ dàng tích
hợp hệ thống DID, tạo nên hệ sinh thái đa dạng và minh bạch trong lĩnh vực
quản lý định danh.
3.2. Kịch bản thử nghiệm
Để thuận lợi cho mục đích nghiên cứu, sẽ thực hiện mô phỏng trên một
máy tính. Trong máy tính này sẽ chứa toàn bộ node xử lý, các thực thể, đồng
thời là nơi diễn ra toàn bộ xử lý tương tác giữa các thực thể.

3.2.1. Chuẩn bị
Máy tính sử dụng có thông số như sau:

STT Yêu cầu Mô tả

Ubuntu phiên bản 16.04 trở lên

1 Hệ điều hành hoặc các bàn phân phối khác của
linux tương tự

Chip xử lý corei5 trở lên có ít

2 CPU
nhất 2 nhân

13
 3 RAM 8GB trở lên

4 Phần cứng 64GB trở lên

Thư viện, phần mềm

5 python3, docker, git, postgresql
chần chuẩn bị

3.2.2. Tổng quan kịch bản

Kịch bản được thiết kế cho Alice, một người tốt nghiệp đại học Faber và
đang hoàn thành hồ sơ để ứng tuyển công việc tại tập đoàn ACME. Xét trong hệ
thống, các thực thể đại diện:
 Alice: Người dùng.
 Trường đại học Faber: Issuer.
 Tập đoàn ACME: đại diện cho Provider.

Hình 3-1: Tương tác giữa các thực thể

3.2.3. Đặc tả chức năng

Chức năng của các thực thể trong hệ thống như sau:

Thực thể Đường dẫn web Chức năng Dữ liệu Dữ liệu

riêng tư công khai

Hệ thống localhost:9009 Điều phối các Không có

chung node trong hệ

14
 thống.

Alice localhost:3000 Yêu cầu chứng Chứng chỉ Khóa công

chỉ từ Faber, cấp học thuật khai DID
quyền xem cho
ACME

Đại học Faber localhost:3002 Tạo và cấp mẫu Khóa công

chứng chỉ khai DID

Tập đoàn localhost:3003 Yêu cầu xem mẫu Khóa công

ACME chứng chỉ từ khai DID
Faber và yêu cầu
xem chứng chỉ từ
Alice

3.3. Triển khai và cài đặt hệ thống giả lập

3.3.1. Cấu hình nội dung tệp cài đặt

Tệp cấu hình pool.dockerfile chứa các thao tác cần thiết để cài đặt hệ
thống mô phỏng thông qua docker.
Nền tảng, thư viện cần sử dụng bao gồm:
 python phiên bản 3.5
 setuptools phiên bản 38.6.0
 aiosqlite phiên bản 0.6.0
Lệnh thực thi:
RUN pip i n s t a l l s e t u p t o o l s −−upgrade
RUN pip i n s t a l l s e t u p t o o l s ==38.6.0
RUN pip i n s t a l l −−no−cache−d i r a i o s q l i t e ==0.6.0

Sau khi cài đặt các thư viện cần thiết, ta cần tạo môi trường docker tên là
RUST_LOG và tạo các thư mục để chuẩn bị cài đặt:
 /ledger/sandbox/data
 /log
 /.indy-cli/networks
 /.indy-client/wallet
Lệnh thực thi:

15
 RUN mkdir −p \
$HOME/ l e d g e r / sandbox / data \
$HOME/ l o g \ $HOME/ . indy−c l i / ne two rks \
$HOME/ . i n d y_ cli e n t / w a l l e t && \

Tiếp theo đó, ta tiến hành cấp quyền đọc, ghi đến các thư mục định tạo
bằng lệnh "CHMOD -R ug+rw [tên thư mục]"
Lệnh thực thi:
chmod −R ug+rw $HOME/ l o g $HOME/ l e d g e r \
$HOME/ . indy−c l i $HOME/ . i n d y_ cli e n t

Ta cần thêm đường dẫn tệp lệnh indy_config.py vừa tạo hệ thống thực thi
lệnh trên terminal.
Lệnh thực thi:
ADD −−chown=indy : indy ind y_config . py / e t c / indy /
ADD −−chown=indy : indy . $HOME

Nội dung tệp pool.dockerfile hoàn chỉnh:

FROM bcgovimages /von−image : py35 −1.6−8
USER indy
RUN pip i n s t a l l s e t u p t o o l s −−upgrade
RUN pip i n s t a l l s e t u p t o o l s ==38.6.0
RUN pip i n s t a l l −−no−cache−d i r a i o s q l i t e ==0.6.0
ENV RUST_LOG ${RUST_LOG:−warning }
RUN mkdir −p \ $HOME/ l e d g e r / sandbox / data \
$HOME/ l o g \ $HOME/ . indy−c l i / ne two rks \
$HOME/ . i n d y_ cli e n t / w a l l e t && \
chmod −R ug+rw $HOME/ l o g
$HOME/ l e d g e r \ $HOME/ . indy−c l i
$HOME/ . i n d y_ cli e n t
ADD −−chown=indy : indy ind y_config . py / e t c / indy /
ADD −−chown=indy : indy . $HOME
RUN chmod uga+x s c r i p t s /∗ bin /∗

3.3.2. Khởi động hệ thống

Chạy lệnh:
$ . / manage build
$ . / manage up

16
 Sau khi chạy lệnh hoàn tất, lúc này ta có thể truy cập vào đường dẫn web
của hệ thống thông qua trình duyệt để xem giao diện của các tác nhân trong kịch
bản đề ra ban đầu.
 Người dùng Alice: Đường dẫn https://localhost:3000.
 Đại học Faber: Đường dẫn https://localhost:3002.
 Tập đoàn ACME: Đường dẫn https://localhost:3003.
 Sổ cái blockchain: Đường dẫn https://localhost:9009.
Hình 3.2 thể hiện giao diện của Alice lúc mới khởi tạo (truy cập vào địa
chỉ https://localhost:3000). Ở phía trên giao diện có các trang con:
 Relationships: Các thực thể đã kết nối cùng Alice.
 Credentials: Thông tin đăng nhập của Alice và chỉ Alice được
quyền quản lý.
 Proof Requests: Các yêu cầu gửi đi về chứng chỉ của Alice mà cần
một bên khác cung cấp.
 Issuing: Trang con mà ở đó Alice cấp chứng chỉ số cho các thực thể
khác. Ở phần sau, tác nhân Faber (đại học nơi Alice theo học) sẽ có
quyền cấp chứng chỉ này cho Alice.
 Messages: Nơi Alice có thể nhắn tin, trao đổi với các tác nhân khác
đã kết nối trong hệ thống.

Hình 3-2: Giao diện của Alice

Ở phía dưới cùng trong hình 3.2, ta có DID (Decentralize-ID) - địa chỉ
công khai mà tác nhân khác có thể đùng để tương tác, kết nối với Alice.

17
 Để theo dõi tiến trình xử lý cũng của các Node trong hệ thống mô phỏng,
ta truy cập đường dẫn https://localhost:9009. Thông tin khởi tạo được xem ở
hình 3.3. Ở đó, mỗi Node có 4 trường thông tin cơ bản:
 DID: ID của Node.
 Uptime: Thời gian tính từ ngày cài đặt
 Transaction: Thông tin xử lý các block.
 Indy Node Version: Phiên bản hiện hành của Node.

Hình 3-3: Thông tin khởi tạo các node

3.3.3. Tiến hành thử nghiệm

Bước 1: Tạo mẫu chứng chỉ cho sinh viên tại đại học Faber
Chọn Issuing ở trang quản lý Faber (http://localhost:3002).
Tại đây, hệ thống sẽ cho ta nhìn thấy mẫu chứng chỉ đăng ký như trong
hình 3.4.

18
 Hình 3-4: Mẫu đăng ký chứng chỉ
Các thuộc tính cần có:
 name: Họ và tên người học.
 degree: Chuyên ngành học.
 status: Tình trạng học (tốt nghiệp hay chưa).
 year: Năm bắt đầu học.
 average: Thời gian học.
 ssn: Mã sinh viên (viết tắt của Social Security Number ).
Bước 2: Tạo kết nối giữa Faber và Alice
Ta truy cập vào trang quản lý của Faber tại đia chỉ https://localhost:3002.
Giao diện hiển thị sẽ như hình 3.5.

19
 Hình 3-5: Giao diện quản lý của đại học Faber
Ở giao diện của Faber, ta chọn nút "Send New Connection Request" và
nhập DID của Alice vào ô địa chỉ. Cuối cùng, ta chọn nút "Send Connection
Request" như hình 3.6 để gửi yêu cầu.

Hình 3-6: Faber gửi yêu cầu kết nối đến Alice
Tiếp sau đó, ta vào trang Messages của Alice. Ở đây, ta sẽ thấy một thư
yêu cầu được kết nối từ phía Faber.

20
 Hình 3-7: Thư yêu cầu được kết nối với Alice gửi từ Faber
Chú ý: Alice cần chắc chắn rằng DID trong yêu cầu là của Faber.
Sau khi đã chắc chắn, ta chọn nút "Accept" có trong thư ở hình 3.7 và
quay lại trang Credentials của Alice sẽ thấy có tài khoản được Faber cấp. Điều
này có nghĩa rằng Alice kết nối thành công với đại học Faber. Kết quả được thể
hiện ở hình 3.8.

Hình 3-8: Alice kết nối thành công với Faber

Bước 3: Alice nhận thông tin chứng chỉ tốt nghiệp từ Faber
Ta vào trang Issuing của Faber từ địa chỉ https://localhost:3002. Ở phần
Relationship, hãy chắc chắn rằng địa chỉ DID là của Alice và mẫu chứng chỉ
chính là mẫu vừa được tạo ở bước 1. Chọn nút "Submit Query" để Faber có thể
cấp chứng chỉ học thuật cho Alice. Quá trình này được biểu diễn ở hình 3.9.

21
 Hình 3-9: Faber cấp chứng chỉ học thuật cho Alice
Tiếp theo, Alice cần truy cập vào trang messages để để chấp nhận chứng
chỉ được cấp bằng cách nhấn vào nút Accept như tỏng hình 3.10.

Hình 3-10: Alice chấp nhận chứng chỉ học thuật

Để kiểm tra xem Alice đã nhận được chứng chỉ học thuật chưa, ta vào
trang Credential của Alice từ địa chỉ https://localhost:3000. Ở đây, ta sẽ nhìn
thấy thông tin chứng chỉ như trong hình 3.11

22
 Hình 3-11: Thông tin chứng chỉ học thuật của Alice
Bước 4: Alice gửi yêu cầu ứng tuyển đến tập đoàn ACME
Từ địa chỉ https://localhost:3000 của Alice, ta chọn yêu cầu kết nối đến
tập đoàn ACME. Hành động này tương tự như hành động ở hình 3.6 khi Faber
muốn kết nối với Alice.
Để tập đoàn ACME có thể kết nối được với với Alice, ta vào trang
Messages từ địa chỉ https://localhost:3003 của ACME và chọn nút "Accept" như
trong hình 3.12.

23
 Hình 3-12: Tập đoàn ACME chấp nhận yêu cầu kết nối từ Alice
Ở bước này, ta coi như Alice đã gửi thành công yêu cầu ứng tuyển đến
làm việc của tập đoàn ACME. Tập đoàn ACME cũng đã biết Alice từng học tại
đại học Faber.
Giờ đây, ACME cần biết thông tin học thuật của Faber. Ta cần vào trang
Proof-Request từ địa chỉ https://localhost:3002 của Faber để xem mẫu yêu cầu
xem chứng chỉ học thuật như hình 3.13. Mẫu yêu cầu xem chứng chỉ được hiển
thị ở bên phải của hình 3.13.

Hình 3-13: Tập đoàn ACME sao chép mẫu yêu cầu xem chứng chỉ từ đại học
Faber
Tiếp theo, tập đoàn ACME sẽ tiến hành kiểm tra chứng chỉ học thuật của
Alice. Ta truy cập vào trang Proof-Request từ địa chỉ https://localhost:3003 của
ACME. Ở bên trái màn hình, hãy chắc chắn địa chỉ DID là thuộc về Alice ở ô
Endpoint DID. Tiếp theo đó, ta chọn chứng chỉ Other và dán mẫu yêu cầu xem
chứng chỉ sang bên phải của màn hình. Cuối cùng, ta chọn nút "Submit Query"
ở bên trái màn hình. Quá trình này được thể hiện trong hình 3.14.

24
 Hình 3-14: ACME gửi yêu cầu xem chứng chỉ của Alice
Hãy luôn ghi nhớ rằng Alice là tác nhân duy nhất quản lý những thông tin
cá nhân của họ, kể cả Faber cũng không được quyền giữ những thông tin này. Vì
thế, tập đoàn ACME vẫn phải chờ Alice chấp thuận mới có thể xem chứng chỉ
học thuật. Ta sẽ chấp thuận yêu cầu từ tập đoàn ACME bằng các vào trang
Message của Alice để mở thư và chọn "Accept" như hình 3.15.

Hình 3-15: Alice cho phép tập đoàn ACME xem chứng chỉ

25
 Ở bước cuối cùng này, tập đoàn ACME nơi Alice xin ứng tuyển công việc
đã có thể xem chứng chỉ học thuật của Alice. Ta vào trang Relationships từ địa
chỉ https://localhost:3003 của ACME để xem những thông tin này như hình
3.16.

Hình 3-16: ACME đã có thể xem chứng chỉ học thuật của Alice
3.4. Kết luận
Qua kịch bản thử nghiệm, ta đã thấy được khả năng tương tác của ba loại
thực thể tham gia trong một hệ thống môi trường Internet: Alice (người dùng),
Faber (bên cung cấp chứng chỉ) và ACME (bên sử dụng những chứng chỉ để
cung cấp dịch vụ).
Ở thời điểm bắt đầu, các thực thể là riêng rẽ và chưa hề có sự liên kết
tương tác nào cả. Qua quá trình tương tác lẫn nhau, các thao tác được thực hiện
mô phỏng quá trình thực tế những tương tác trong môi trường Internet (tạo tài
khoản, cung cấp thông tin định danh, sử dụng dịch vụ được cung cấp). Các
thông tin trao đổi qua thư luôn được dùng dưới một khóa gọi là DID, nhằm đảm
bảo tính bảo mật. Các thông tin trao đổi cũng hạn chế tối đa thông tin cần thiết.
Kết quả cuối cùng, các thực thể đều có đã nhận được thông tin cần thiết
để phục vụ nhiệm vụ của mình. Quá trình xác thực, lưu trữ các thông tin này
được thực hiện nhờ các Node chạy ẩn trong blockchain của Indy.

26
 KẾT LUẬN
Sau khi trình bày các kiến thức cơ bản, đề xuất và xây dựng mô hình quản
lý định danh điện tử dựa trên công nghệ Blockchain, bài báo cáo đã đạt được
những kết quả và hạn chế sau:
Kết quả
- Trình bày về công nghệ Blockchain, lịch sử ra đời, quá trình phát
triển cũng như các khái niệm cơ bản và mô hình hoạt động của nền
tảng công nghệ Blockchain.
- Trình bày về khả năng ứng dụng, những khó khăn gặp phải và các
loại Blockchain khác nhau.
- Trình bày về khái niệm danh tính điện tử, các mô hình quản lý định
danh hiện tại.
- Trình bày về mô hình định danh tự chủ và công nghệ Hyperledger
Indy.
- Triển khai hệ thống định danh tự chủ dự trên công nghệ
Hyperledger Indy.
Hạn chế
- Bài báo cáo tận dụng nhiều nền tảng mã nguồn mở, nhiều
framework khác nhau, chưa xây dựng dựa trên một blockchain tự
thiết kế, phải phụ thuộc vào nền tảng Blockchain do bên thứ ba
cung cấp.
- Quá trình hoạt động chưa tự động hoá, vẫn phải thao tác phê duyệt,
thêm giao dịch thủ công.
Hướng phát triển trong thời gian tới
- Tích hợp hệ thống Blockchain tự thiết kế, tránh phụ thuộc.
- Phát triển hợp đồng thông minh để tự động hoá các quá trình.

27
 TÀI LIỆU THAM KHẢO

[1] Marcos Allende López -The Future of Identity: Self-Sovereignity,

Digital Wallets, and Blockchain (2020)
[2] Sovrin Foundation - The Inevitable Rise of Self-Sovereign Identity
(2017)
[3] Christopher Allen - The Path to Self-Sovereign Identity (2016)
[4] Documents from Hyperledger Indy Hyperledger Indy — Hyperledger
Indy 1.0 documentation (hyperledger-indy.readthedocs.io)
[5] An Introduction to Hyperledger - Hyperledger Foundation

28