Ứng dụng điện toán đám mây trong việc kiểm soát an toàn phục vụ

3. Cấu trúc luận văn

3.3 Ứng dụng điện toán đám mây trong việc kiểm soát an toàn phục vụ

vụ nhu cầu theo dõi sức khỏe

Trong xu hướng hội nhập và phát triển hiện nay, công nghệ thông tin đã trở thành công cụ không thể thiếu trong công việc hàng ngày của cán bộ, công chức, viên chức tại các cơ quan, đơn vị ngành Y tế, nhằm giúp công tác quản lý, điều hành thuận lợi, hiệu quả, tiết kiệm chi phí, thúc đẩy cải cách hành chính, nâng cao chất lượng, hiệu quả công việc.

Việc nghiên cứu, ứng dụng công nghệ thông tin trong vấn đề theo dõi sức khỏe đang được rất nhiều đơn vị tổ chức triển khai. Tuy nhiên, đi song hành với vấn đề này chính là vấn đề bảo vệ dữ liệu người sử dụng khi tham gia theo dõi sức khỏe.

Dữ liệu y tế được dùng để theo dõi toàn bộ các quá trình giao dịch cũng như sự kiện giữa bệnh nhân và dịch vụ chăm sóc sức khỏe. Chúng cung cấp đầy đủ thông tin cá nhân của bệnh nhân cũng như các thông tin về bệnh tật, tiền sử bệnh tật, chẩn đoán, các phương pháp điều trị, các xét nghiệm và các dịch vụ y tế khác trong quá khứ. Các dữ liệu này sẽ giúp các đội ngũ y bác sỹ đánh giá và phân tích được các xu hướng trong hoạt động chăm sóc sức khỏe, đặc điểm bệnh nhân và chất lượng chăm sóc sức khỏe, các dữ liệu này sẽ được cập nhật phục vụ công tác truy cứu, điều trị và chữa trị của bệnh nhân sau này.

Các dữ liệu này được đánh giá là rất quan trọng đối với không chỉ đối với bệnh nhân mà còn cả đối với cả các y bác sỹ. Xu hướng ứng dụng công nghệ thông

36 tin trong việc lưu trữ, quản lý và khai thác các dữ liệu y tế đã và đang được triển khai, tuy nhiên đi kèm với đó chính là sự gia tăng của rủi ro về an toàn và bảo mật, chẳng hạn nguy cơ rõ rỉ, mất mát dữ liệu là rất lớn.

Trong phần này, chúng tôi sẽ trình bày cụ thể giải pháp của chúng tôi đưa ra trong vấn đề ứng dụng trong việc kiểm soát an toàn phục vụ nhu cầu theo dõi sức khỏe cộng đồng.

3.3.1 Thu thập dữ liệu

Đặc trưng dữ liệu y tế Dữ liệu y tế trong nghiên cứu này được phân thành 2 nhóm: Dữ liệu thu thập từ các thiết bị y sinh và dữ liệu thông tin bệnh án. Phần dưới đây mô tả đặc trưng nguồn dữ liệu đầu vào cho hệ thống HealthDL [14].

Các thiết bị y sinh như máy đo nhịp tim, huyết áp gửi thông số đo khoảng 540 bytes/s. Trung bình mỗi bệnh nhân đo 2 tiếng/ngày, như vậy số lượng gói dữ liệu sinh ra trong 1 tháng ứng với 1.000 bệnh nhân là 216.000.000 gói dữ liệu. Mỗi gói trung bình 540 bytes, xét trên 1.000 bệnh nhân với các máy đo độc lập, lượng dữ liệu thu thập được tương ứng là 116 Gigabytes về thông số bệnh nhân trong một tháng.

Xét dữ liệu bệnh án tìm hiểu trên 4 nhóm bệnh, gồm: Bệnh tăng huyết áp (kích thước bản ghi 800-1.000 bytes); bệnh lao phổi (kích thước bản ghi 400-600 bytes); bệnh hen phế quản (kích thước bản ghi 500-700 bytes); bệnh đái tháo đường (kích thước bản ghi 800-1.000 bytes). Đặc điểm của dữ liệu bệnh án là cấu trúc dữ liệu rất linh hoạt. Đối với bệnh nhân đái tháo đường, một văn bản bệnh án sẽ có khoảng 150 trường dữ liệu riêng biệt với cấu trúc chia nhỏ từ 4 đến 5 tầng (bảng 1). Đối với bệnh nhân tăng huyết áp, một văn bản bệnh án sẽ có khoảng 75 trường dữ liệu riêng biệt với cấu trúc chia nhỏ đến 4-5 tầng.

Như vậy có thể thấy, nguồn dữ liệu y tế trong hệ thống HealthDL mang đặc trưng của dữ liệu lớn. Cụ thể:

Kích thước lớn: Xét trên 1.000 bệnh nhân với các máy đo độc lập, lượng dữ

liệu thu thập được tương ứng là 116 Gigabytes về thông số bệnh nhân trong một tháng. Như vậy, khi số bệnh nhân tăng lên và thời gian đo kéo dài, lượng dữ liệu cần thu thập là vô cùng lớn.

Tốc độ lớn: Các thiết bị y sinh tạo ra dữ liệu liên tục với tốc độ cao (tần suất

1 bản ghi dữ liệu/s) đòi hỏi hệ thống lưu trữ cần đảm bảo tính sẵn sàng cao, đáp ứng tương tranh đồng thời giữa các tiến trình ghi dữ liệu và các tiến trình đọc, xử lý dữ liệu theo thời gian thực.

37

Tính đa dạng: Các bệnh án là dữ liệu bán cấu trúc có lược đồ không đồng

nhất. Việc lưu trữ dữ liệu này đòi hỏi hệ quản trị cơ sở dữ liệu phải có lược đồ dữ liệu linh hoạt, điều mà các hệ quản trị cơ sở dữ liệu quan hệ truyền thống không đáp ứng được.

Mang lại giá trị lớn: Dữ liệu y tế được lưu trữ và khai thác mang lại hiệu quả

cao trong việc chẩn đoán, điều trị bệnh, góp phần cải thiện chất lượng khám chữa bệnh và giảm chi phí xét nghiệm.

3.3.2 Mã hóa AES

Năm 1997, NIST (National Institute of Standards and Technology) đã mở một cuộc thi dành cho các thiết kế cải tiến thuật toán mã khối với khóa mã đối xứng. Kết quả chọn được thuật toán Rijandel: Một thuật toán mã do hai người Bỉ (Joan Daemen và Vincent Rijmen) đề xuất [35,36] là thuật toán có tốc độ mã hóa và giải mã nhanh nhất. Thuật toán này được NIST lựa chọn và trở thành tiêu chuẩn Quốc gia, gọi là Chuẩn mã hóa dữ liệu tiên tiến AES. Đây là chuẩn mã khối được xây dựng trên cơ sở cấu trúc mạng thay thế hoán vị (SPN) với kích thước khối là 128 bit. Mỗi khối đầu vào được biểu diễn dưới dạng ma trận 4x4 trên trường 𝔽28. Cấu trúc tổng thể của AES được mô tả như trong hình:

Hình 3.3: Cấu trúc tổng thể của thuật toán AES

3.3.2.1 Khái niệm

Rijndael là một mã khối với độ dài khối và độ dài khoá đều có thể thay đổi. Độ dài khối và độ dài khoá được gán một cách độc lập bằng bội của 32 bit, với 128 bit là nhỏ nhất và 256 bit là lớn nhất. AES là một trường hợp riêng của

38 Rijndael. AES có độ dài khối bằng 128 bit và hỗ trợ các độ dài khoá bằng 128, 192 hay 256 bit.

Sau đây là mô tả của Rijndael. Đầu vào và đầu ra của Rijndael được xem như là các mảng một chiều của các byte có 8 bit. Đối với phép mã, đầu vào là khối rõ (plaintext block) và khoá (key), và đầu ra là bản mã (ciphertext block). Đối với phép giải mã, đầu vào là khối mã và khoá, đầu ra là khối rõ. Biến đổi vòng của Rijndael, và các bước của nó, thao tác trên một kết quả trung gian, được gọi là trạng thái (state). Trạng thái có thể được vẽ như là một mảng chữ nhật các byte, với 4 dòng. Số các cột trong trạng thái được ký hiệu bởi Nb và bằng độ dài khối chia cho 32 (đối với AES thì Nb bằng 4). Giả sử khối rõ được ký hiệu bởi

𝑝0𝑝1𝑝2𝑝3. . . . 𝑝4.𝑁𝑏−1 (14)

với p0 ký hiệu byte đầu tiên, và 𝑝4.𝑁𝑏−1 ký hiệu byte cuối cùng của khối bản rõ.

Tương tự, khối bản mã có thể được ký hiệu bởi: 𝑐0𝑐1𝑐2𝑐3. . . . 𝑐4.𝑁𝑏−1 (15) Giả sử trạng thái được ký hiệu bởi

𝑎𝑖,𝑗, 0 ≤ 𝑖 < 4,0 ≤ 𝑗 < 𝑁𝑏 (16)

với ai,j ký hiệu byte ở tại dòng i và cột j. Các byte đầu vào được ánh xạ thành các byte trạng thái theo thứ tự a0,0, a1,0, a2,0, a3,0, a0,1, a1,1, a2,1, a3,1, ...

Đối với phép mã, đầu vào là khối rõ và ánh xạ là aij = pi+4j, 0  i < 4, 0  j < Nb. (17) Đối với phép giải mã, đầu vào là bản mã và ánh xạ là

aij = ci+4j, 0  i < 4, 0  j < Nb. (18)

Tại điểm kết thúc của phép mã, bản mã được lấy ra từ trạng thái bằng các lấy các byte trạng thái theo thứ tự:

ci = ai mod 4, i/4, 0  i < Nb. (19)

Tại điểm kết thúc của phép giải mã, khối rõ được lấy ra từ trạng thái theo cách:

pi = ai mod 4, i/4, 0  i < Nb. (20)

Tương tự, khoá được ánh xạ thành khoá mã 2-chiều. Khoá mã được vẽ như một mảng chữ nhật với 4 dòng tương tự như trạng thái. Số các cột của khoá mã

39 được ký hiệu bởi Nk và bằng độ dài khoá chia cho 32. Các byte của khoá được ánh xạ thành các byte của khoá mã theo thứ tự: k0,0, k1,0, k2,0, k3,0, k0,1, k1,1, k2,1, k3,1, k0,2, .... Nếu chúng ta ký hiệu khoá bởi

𝑧0𝑧1𝑧2𝑧3. . . . 𝑧4.𝑁𝑘−1(21) thì

ki,j = zi+4j, 0  i < 4, 0  j < Nk. (22)

Biểu diễn của trạng thái và khoá mã và các ánh xạ bản rõ-trạng thái, khoá- khoá mã (key- cipher key) được minh hoạ ở hình sau.

p0 p4 p8 p12 k0 k4 k8 k12 k16 k20

p1 p5 p9 p13 k1 k5 k9 k13 k17 k21

p2 p6 p10 p14 k2 k6 k10 k14 k18 k22

p3 p7 p11 p15 k3 k7 k11 k15 k19 k23

Bảng 3.1: Cách bố trí của trạng thái và khoá mã cho trường hợp Nb= 4 và Nk = 6.

3.3.2.2 Cấu trúc của Rijdael

Ba tiêu chuẩn thiết kế được tính đến trong thiết kế của Rijndael là như sau:

• Có khả năng chống lại tất cả các tấn công đã biết;

• Tốc độ và tính gọn của mã lệnh trên một miền rộng của các kiến trúc (platform)

• Tính đơn giản của thiết kế

Rijndael là một mã khối lặp bằng cách áp dụng lặp một ánh xạ vòng trên trạng thái. Số các vòng được ký hiệu bởi Nr và phụ thuộc vào độ dài khối và độ dài khoá. Các lựa chọn cụ thể cho các tầng khác nhau một phần lớn dựa trên việc áp dụng của Chiến lược vệt lan rộng, đó là một phương pháp thiết kế đảm bảo tính kháng cự chống lại phân tích vi sai và tuyến tính.

Phép mã của Rijndael bao gồm phép cộng khoá ban đầu, được ký hiệu bởi AddRoundKey, sau đó là Nr-1 lần áp dụng biến đổi Round, và cuối cùng là một lần áp dụng FinalRound. Phép cộng khoá ban đầu và mỗi vòng nhận đầu vào là State và khoá vòng. Khoá vòng cho vòng i được ký hiệu bởi ExpandedKey[i], còn ExpandedKey[0] ký hiệu đầu vào của phép cộng khoá ban đầu. Việc nhận được

40 ExpandedKey từ CipherKey được ký hiệu bởi KeyExpansion. Mô tả mức cao của Rijndael ở dạng giả mã-C được cho sau đây.

Trước vòng đầu tiên, tầng cộng khoá được áp dụng. Để làm cho chính phép mã hóa và phép giải mã tương tự về mặt cấu trúc, tầng trộn tuyến tính của vòng cuối cùng là khác với tầng trộn tuyến tính trong các vòng khác.

Trong luận văn này, chúng tôi không đi sâu vào các quy trình cụ thể cũng như các bước thực thi của mã hóa và giải mã AES, phần tiếp theo trong luận văn đó chính là chuyển đổi từ mã hóa AES sang FHE.

3.3.3 Chuyển đổi mã hóa AES sang FHE

Vì không thể thực hiện mã hóa đồng cấu trong giai đoạn thu thập, nên dữ liệu phải được truyền vào đám mây ở định dạng được mã hóa AES. Phương án được đề xuất là lưu trữ tất cả dữ liệu bệnh nhân ở định dạng được mã hóa AES, vì AES là một chuyển đổi lưu trữ (tức là phiên bản được mã hóa AES của dữ liệu thô 128 bit cũng chiếm 128 bit). Mặc dù điều này hoàn toàn giải quyết được quyền riêng tư của dữ liệu được lưu trữ, nhưng việc chuyển đổi dữ liệu được mã hóa AES sang dữ liệu được mã hóa FHE phải được thực hiện tại một số điểm, trước khi có thể thực hiện bất kỳ tính toán nào bằng cách sử dụng FHE.

Việc chuyển đổi dữ liệu được mã hóa AES sang dữ liệu được mã hóa FHE yêu cầu đánh giá chức năng giải mã AES một cách đồng cấu. Để ước tính chi phí chuyển đổi AES sang FHE, trong (Gentry et al., 2012), các tác giả đã triển khai chức năng giải mã AES-128 với lược đồ BGV (Brakerski et al., 2012) và cung cấp phân tích độ trễ / thông lượng với các lựa chọn thiết kế khác nhau. Giải mã AES-128 hoạt động trên các khối dữ liệu 128 bit (tức là 16B), trong đó mức độ chi tiết của các hoạt động là 1 Byte. Trong thiết kế đầu tiên, một bản mã được đặt để chứa 864 khe văn bản rõ trong đó mỗi khe chứa thông tin cho bản tin 1B. Với cài đặt này, 16 khe cắm có thể được sử dụng để chứa một dữ liệu được mã hóa AES, do đó ⌊864 ÷ 16⌋ = 54 hoạt động giải mã AES có thể được thực hiện song

Rijndael(State, CipherKey) {

KeyExpansion(CipherKey, ExpandedKey); AddRoundKey(State, ExpandedKey[0]);

For (i = 1; i < Nr; i++) Round(State, ExpandedKey[i]); FinalRound(State, ExpandedKey[Nr]);

41 song. Đánh giá tổng thể chạy trong 36 giờ; tuy nhiên vì 54 giải mã AES đã được thực hiện song song, thông lượng là khoảng 40 phút cho một lần giải mã AES. Trong thiết kế thứ hai, 16 bản mã được sử dụng và mỗi bản mã được thiết lập để chứa 720 khe văn bản rõ. Tương tự như cài đặt thiết kế đầu tiên, mỗi khe chứa thông tin cho bản tin 1B, nhưng lần này mỗi khe được liên kết với dữ liệu được mã hóa AES khác nhau, do đó hoạt động giải mã 720 AES có thể được thực hiện song song. Mặc dù với cài đặt này, tổng thời gian đánh giá là khoảng 5 ngày, thông lượng cho một lần giải mã AES giảm xuống còn 5 phút. Mặc dù thiết kế thứ hai cung cấp kết quả thông lượng tốt hơn thiết kế đầu tiên, nhưng nó yêu cầu bộ nhớ lớn hơn để lưu trữ tất cả các biến. Và phương án được đưa ra ở đây là sử dụng cài đặt thiết kế đầu tiên làm tài liệu tham khảo.

Dựa trên kết quả được báo cáo trong (Gentry et al., 2012) là khoảng 36 giờ để giải mã 54 khối AES (mỗi khối 16B), cần khoảng 150 giây để chuyển đổi 1B. Sử dụng các kết quả này làm cơ sở, các tác giả đã tính toán rằng, tác nhân chuyển đổi AES sang FHE sẽ cần xử lý 87.896 chú thích nhịp (175.792B giả sử 2B cho mỗi phần tử chú thích) để chuyển đổi bản ghi chú thích của bệnh nhân 24 giờ thành FHE. Do đó, thời gian tính toán cho việc chuyển đổi này là khoảng 7.324 giờ. Sử dụng thời gian chuyển đổi ước tính, tốc độ tăng tốc cần thiết là khoảng 305 lần để tính toán kết quả theo tốc độ đến (tức là 24 giờ). Phương pháp đã trình bày cách có thể song song hóa quá trình này để thực hiện chuyển đổi AES sang FHE ở tốc độ tối đa nếu có đủ khả năng song song phần cứng.

3.3.4 Lưu trữ và tính toán trong đám mây

Để hoạt động trên dữ liệu y tế với FHE, hồ sơ y tế được mã hóa AES phải được chuyển đổi sang phiên bản mã hóa FHE.

Việc chuyển đổi AES sang FHE có thể được thực hiện ngoại tuyến trong khi thời gian chuyển đổi sẽ được hiển thị do sự chậm trễ trong việc cung cấp dữ liệu bệnh nhân được theo dõi từ xa cho bác sĩ. Sự chậm trễ này có thể không quan trọng, vì bác sĩ thường cần những kết quả này trong vài ngày sau khi hoàn thành việc theo dõi từ xa. Dung sai độ trễ này có thể được chuyển thành tiết kiệm chi phí hơn nữa cho HCO, bằng cách thực hiện chuyển đổi AES sang FHE khi tài nguyên tính toán ít tốn kém hơn. Ví dụ: Amazon Web Services (AWS) cung cấp các phiên bản Micro có khả năng tính toán cơ bản nhưng chúng có thể được thuê miễn phí.

Ngoài sự chậm trễ trong việc cung cấp chuyển đổi AES sang FHE, một số lượng tính toán nhất định cũng có thể được thực hiện ngoại tuyến. Ví dụ: giả sử một tập hợp 10.000 kết quả cần được thêm vào để cung cấp nhịp tim trung bình

42 cho bác sĩ. Những kết quả cần thêm này thường nằm trong những khoảng thời gian rất dễ dự đoán, do đó tạo ra các mẫu có thể dự đoán được trong các kết quả có thể tính toán trước. Ví dụ: để giảm bớt thời gian thực trên đám mây khi bác sĩ đang chạy ứng dụng, cứ 100 kết quả có thể được tính tổng và kết quả có thể được lưu trữ trong vùng lưu trữ. Quá trình như vậy có thể được đẩy nhanh bằng cách sử dụng các máy gia tốc chuyên dụng (Guo et al, 2010; Soyata et al, 2012a) và các kỹ thuật tối ưu hóa tính toán (Soyata et al, 1993; Soyata & Friedman, 1994a; Soyata & Friedman, 1994b; Soyata et al, 1995; Soyata & Friedman, 1997; Soyata,