Đánh giá mô hình bảo mật cho mạng vạn vật dựa trên OneM2M
Kỷ yếu Hội nghị KHCN Quốc gia lần thứ XI về Nghiên cứu cơ bản và ứng dụng Công nghệ thông tin (FAIR); Hà Nội, ngày 09-10/8/2018
DOI: 10.15625/vap.2018.00016
ĐÁNH GIÁ MÔ HÌNH BẢO MẬT CHO MẠNG VẠN VẬT
DỰA TRÊN OneM2M
Nguyễn Văn Tánh, Nguyễn Gia Tuyến, Mạc Đình Hiếu, Bùi Trọng Tùng, Trần Quang Đức, Nguyễn Linh Giang
Trung tâm An toàn và An ninh thông tin, Trường Đại học Bách khoa Hà Nội
TÓM TẮT: Mạng vạn vật (Internet of Things) đang được ứng dụng rộng rãi trong cuộc sống từ các hoạt động công nghiệp, tự động
hóa, giám sát môi trường, vận chuyển hàng hóa đến các hệ thống hỗ trợ cuộc sống như nhà thông minh, thành phố thông minh,
giám sát và chăm sóc sức khỏe,… Bên cạnh các lợi ích to lớn, IoT cũng tồn tại rất nhiều các thách thức như sự đa dạng và phức tạp
của các quy chuẩn kết nối, sự không đồng nhất về phần cứng, phần mềm, cơ chế liên lạc của các thiết bị IoT trong hạ tầng mạng.
Các mô hình và giải pháp bảo mật truyền thống không còn phù hợp và hiệu quả với kiến trúc hạ tầng mạng trong môi trường IoT.
Trong bài báo này chúng tôi giới thiệu mô hình bảo mật cho mạng vạn vật dựa trên chuẩn OneM2M và đề xuất áp dụng mô hình
trong hệ thống hỗ trợ giám sát, theo dõi sức khỏe bệnh nhân theo thời gian thực bằng hệ thống cảm biến y tế. Chúng tôi cũng tiến
hành triển khai một phiên bản thử nghiệm đơn giản của hệ thống trên trong môi trường thực tế để đánh giá tính khả thi của việc
truyền nhận dữ liệu bảo mật giữa các thiết bị cảm biến y tế và hệ thống OM2M bằng giao thức DTLS. Các kết quả triển khai thực
nghiệm của hệ thống trong thực tế sẽ chỉ ra tính hiệu quả của mô hình đề xuất cũng như các thách thức cần giải quyết.
Từ khóa: IoT, oneM2M, DTLS, OM2M, An toàn thông tin cho mạng vạn vật.
I. GIỚI THIỆU
Mạng vạn vật hay mạng lưới vạn vật kết nối Internet (Internet of Things - IoT) là khái niệm mở rộng của mạng
Internet, khi mà mạng Internet trở thành mạng lưới kết nối và giao tiếp giữa rất nhiều loại thiết bị khác nhau từ các
thiết bị đơn giản như thiết bị cảm biến cho đến các hệ thống tính toán phức tạp như siêu máy tính. Hiện nay, các thiết
bị IoT đang được ứng dụng và triển khai trong rất nhiều lĩnh vực gồm giám sát theo dõi môi trường, hệ thống nhà
thông minh, thành phố thông minh, hệ thống quản lý và điều khiển tự động hóa trong công nghiệp, hệ thống quản lý y
tế, giám sát và chăm sóc sức khỏe,… Trong môi trường IoT, việc truyền thông giữa máy với máy (M2M – Machine to
Machine) là xương sống của hạ tầng mạng, các thiết bị giao tiếp với nhau để thu thập, lưu trữ và truyền tải thông tin.
Việc giao tiếp thông thường được thực hiện thông qua các chuẩn kết nối với một chồng giao thức chung như trong
mạng Internet truyền thống các máy tính có thể kết nối với nhau bằng các chuẩn Wifi (IEEE 802.11), Ethernet (IEEE
802.3) hoặc truyền thông di động như 3G, LTE, Wimax,… nhưng đều sử dụng chung chồng giao thức TCP/IP. Tuy
nhiên, do yêu cầu đặc biệt về tính năng của sản phẩm như nhỏ gọn, di động, tiêu thụ điện năng thấp, truyền thông tầm
ngắn và yêu cầu phần cứng đặc biệt khác mà các nhà sản xuất IoT sử dụng các chuẩn kết nối mới như NFC, BLE,
Zigbee, IEEE 802.15.4, LoRa, Sigfox, ... để tích hợp vào sản phẩm của mình. Vì vậy IoT là sự kết nối của một tập các
mạng không đồng nhất với nhau như WSN, WPAN, WLAN. Trong cùng một mạng, các thiết bị sẽ sử dụng chung một
bộ giao thức để kết nối và trao đổi thông tin và các mạng khác nhau sẽ giao tiếp thông qua các Gateway trung gian có
nhiệm vụ chuyển đổi dữ liệu giữa các giao thức [5].
Hiện có rất nhiều các công trình nghiên cứu đã được công bố [1-7], trong đó các tác giả đã tiến hành khảo sát và
đưa ra bức tranh tổng thể IoT, từ các kiến trúc mạng cơ bản, sự phân mảnh của công nghệ và chuẩn giao thức kết nối
cho đến các ứng dụng tiềm năng, các vấn đề tồn tại và thách thức cần giải quyết của IoT. Hiện nay, do vẫn chưa có một
bộ tiêu chuẩn toàn cầu thống nhất nên các nhóm nghiên cứu, tổ chức khác nhau đã xây dựng, phát triển và đưa ra các
bộ tiêu chuẩn riêng cho IoT. Các bộ tiêu chuẩn được sử dụng rộng rãi là AllSeen Alliance, OCF, OneM2M, Thread
Group, IEEE P2413 Working Group, IETF, ISO/IEC, IIC [2]. Trong đó, bộ tiêu chuẩn oneM2M cho M2M và IoT của
tổ chức OneM2M [8], ra đời năm 2012 dưới sự hỗ trợ của 8 tổ chức tiêu chuẩn toàn cầu (ARIB, ATIS, ETSI, …) và 6
tập đoàn công nghiệp lớn (AT&T, Adobe, Ericsson, IBM, …) cùng hơn 200 thành viên khác là được sử dụng rộng rãi
và phổ biến nhất. OneM2M đề xuất các giao thức chuẩn cho IoT theo từng tầng của kiến trúc mạng như minh họa tại
hình 1.a. Các giao thức này bao gồm các giao thức mạng truyền thống và các giao thức mạng mới được phát triển cho
“things” trong IoT. Minhaj Ahmad Khan và các cộng sự [6] đã chỉ ra trong một mạng IoT điển hình sẽ bao gồm các
thiết bị không đồng nhất, trong đó bao gồm các thiết bị nhỏ gọn, hạn chế về năng lượng, tài nguyên tính toán và bộ
nhớ. Chính vì sự hạn chế về phần cứng, các thiết bị này giao tiếp với nhau thông qua mạng cá nhân, không dây tốc độ
thấp LR-WPAN (Low Rate Wireless Personal Area Networks) và các giao thức mới được phát triển cho mạng năng
lượng thấp LPWAN (Low Power Wire Area Network). Trong mạng LR-WPAN và LPWAN, các thiết bị sử dụng các
giao thức được thiết kế để tiêu thụ ít năng lượng như giao thức IEEE 802.15.4 [9] định nghĩa lớp vật lý – Physic và lớp
điều khiển truy cập – MAC cho kết nối giao tiếp tầm ngắn (<100 m), tốc độ thấp (<250 kps), tiêu thụ năng lượng ít
(thời gian hoạt động tính theo tháng hoặc năm), nhỏ gọn (kích thước chồng giao thức <32 kb) phù hợp với các thiết bị
IoT trong các ứng dụng giám sát và điều khiển. Trước đây, việc mở rộng IP cho mạng LPWPAN được xem là không
thực tế vì các mạng đó bị hạn chế về khả năng xử lý và phải hoạt động bằng pin trong một thời gian dài. Tuy nhiên, sự
ra đời của giao thức 6LoWPAN đã tạo ra một lớp thích ứng cho phép giao tiếp hiệu quả IPv6 trên chuẩn IEEE 802.15.4
[10]. 6LoWPAN đề xuất một cơ chế nén tiêu đề gói tin và cơ chế phân mảnh IPv6 datagram để truyền được gói tin
Nguyễn Văn Tánh, Nguyễn Gia Tuyến, Mạc Đình Hiếu, Bùi Trọng Tùng, Trần Quang Đức, Nguyễn Linh Giang
121
IPv6 trong các mạng không dây sử dụng chuẩn kết nối IEEE 802.15.4 với Maximum Transmission Unit (MTU) chỉ
127 byte. IPv6 với số lượng địa chỉ gần như không giới hạn cho phép mỗi một thiết bị trong IoT được định danh bởi
một địa chỉ duy nhất. Các giao thức tầng ứng dụng truyền thống như HTTP và HTTPS không phù hợp để triển khai
trên các thiết bị IoT do hạn chế về kích thước của gói tin của chuẩn IEEE 802.15.4 cũng như hạn chế về tài nguyên tính
toán. Tổ chức IETF đã xây dựng giao thức CoAP (Constrained Application Protocol) [11], một giao thức ứng dụng
tương tự HTTP những đã được tối ưu cho các thiết bị IoT. Giao thức CoAP được đóng gói trong giao thức UDP của
tầng giao vận và tương thích với giao thức 6LoWPAN. Tuy nhiên, với việc UDP thiếu tính tin cậy và các gói tin có thể
mất mát trong quá trình truyền tin nên để có thể đảm bảo an toàn và bảo mật cho quá trình truyền tin các thiết bị này
phải sử dụng giao thức DTLS. Bên cạnh CoAP, trong chuẩn OneM2M cũng sử dụng giao thức MQTT (Message
Queuing Telemetry Transport) [12] cho quá trình trao đổi thông điệp giữa M2M và các thiết bị IoT. MQTT là một giao
thức gửi thông điệp theo cơ chế publish/subcscribe với băng thông thấp, độ tin cậy cao và khả năng được sử dụng trong
mạng lưới không ổn định.
Chuẩn oneM2M cho phép xây dựng một nền tảng kết nối M2M để các ứng dụng trong các lĩnh vực khác nhau
được triển khai độc lập không bị phụ thuộc vào tầng mạng phía dưới, phát triển các dịch vụ ngang hàng (CSE-
Common Service Capability) thay vì các triển khai các dịch vụ riêng lẻ trên một hạ tầng mạng IoT độc lập với nhau.
Tuy nhiên việc đảm bảo an toàn bảo mật cho toàn bộ hệ thống hay việc có thể triển khai các cơ chế bảo mật giữa các
thiết bị không đồng nhất trong hệ thống vẫn là một thách thức lớn, đặc biệt khi triển khai trên các thiết bị trong môi
trường thực tế. Các tác giả [16], [17] đã đề xuất các cơ chế nén tiêu đề DTLS trên 6LoWPAN để giảm kích thước của
các gói tin DTLS cho phép tích hợp được CoAP, DTLS trên các thiết bị IoT. Tuy nhiên các tác giả không tiến hành
đáng giá hiệu năng của các giao thức này trên một thiết bị thực tế nên không chứng minh được tính khả thi của cơ chế
đề xuất. Perelman [18] và Glissa [19] đã triển khai các giao thức TLS/DTLS trên Contiki OS, hệ điều hành cho các
thiết bị IoT. Các tác giả đã đánh giá việc triển khai các giao thức này trên các thiết bị thực tế, tuy nhiên các thử nghiệm
chỉ giới hạn trong phạm vi kết nối giữa 2 nút mạng sử dụng giao thức 6LoWPAN mà không đánh giá trong ngữ cảnh
của một ứng dụng cụ thể. Diogo và các cộng sự [20] đã đề xuất hệ thống giám sát theo thời gian thực dựa trên chuẩn
oneM2M với giao thức MQTT và triển khai đánh giá trên các thiết bị thực tế, tuy nhiên hệ thống đề xuất lại thiếu các
cơ chế bảo mật cần thiết.
Trong bài báo này, chúng tôi giới thiệu mô hình bảo mật cho IoT dựa theo chuẩn oneM2M và đề xuất áp dụng
mô hình này trong hệ thống hỗ trợ giám sát và theo dõi sức khỏe của bệnh nhân bằng các cảm biến y tế. Hệ thống được
triển khai dựa trên nền tảng mã nguồn mở OM2M và sử dụng bộ giao thức TLS/DTLS để đảm bảo an toàn cho việc
tryền nhận dữ liệu điều khiển và các thông tin y tế giữa các thiết bị cảm biến và các ứng dụng quản lý. Bài báo của
chúng tôi gồm 4 nội dung chính. Sau phần giới thiệu, phần II chúng tôi đề cập đến cơ sở lý thuyết. Phần III chúng tôi
trình bày cụ thể về mô hình bảo mật cho IoT và triển khai mô hình trong hệ thống hỗ trợ giám sát và theo dõi sức khỏe
của bệnh nhận thông qua các cảm biến y tế. Phần IV chúng tôi sẽ trình bày các thử nghiệm và đánh giá thực tế để chỉ ra
được tính khả thi và hiệu quả của giải pháp cũng như các thách thức cần phải giải quyết. Cuối cùng phần V là kết luận
và hướng phát triển trong tương lai.
II. CƠ SỞ LÝ THUYẾT
2.1. Chuẩn oneM2M và nền tảng mã nguồn mở OM2M
OneM2M cung cấp một nền tảng dịch vụ M2M ngang hàng để có thể phát triển các dịch vụ một cách độc lập
với các hạ tầng mạng phía dưới thuận tiện cho việc triển khai đồng thời các ứng dụng đặc thù trên cùng một mạng các
thiết bị hỗn tạp như IoT. Các dịch vụ được cung cấp thông qua kiến trúc RESTful cho phép các thiết bị IoT không đồng
nhất có thể yêu cầu và truy cập các dịch vụ một các đơn giản và hiệu quả. Chính vì vậy, các thiết bị hỗ trợ giao thức
ứng dụng REST như HTTP hoặc CoAP có thể dễ dàng tương thích với OM2M. Kiến trúc theo chức năng của oneM2M
được minh họa tại hình 1.b. gồm ba thực thể chức năng chính phân theo ba tầng. Thứ nhất AE (Application Entity) là
một thực thể đại diện cho một ứng dụng chuyên biệt trong các lĩnh vực khác nhau được cung cấp cho người dùng đầu
cuối trong giải pháp M2M. Mỗi AE có một định danh duy nhất là AE-ID. Các ứng dụng như theo dõi các phương tiện
giao thông, ứng dụng giám sát lượng đường trong máu từ xa, ứng dụng giám sát môi trường hoặc ứng dụng điều khiển
là các ví dụ tiêu biểu cho một AE. Thành phần chức năng thứ 2 trong kiến trúc oneM2M là CSE (Common Services
Entity) là các thực thể đại diện cho một tập hợp các dịch vụ được chia sẻ chung trong oneM2M. Các dịch vụ như vậy
kết nối với các thực thể khác thông qua điểm tham chiếu Mca và Mcc. Điểm tham chiếu Mcn được sử dụng để truy cập
dịch vụ mạng được cung cấp bởi các thực thể đại diện cho hạ tầng mạng ở phía dưới. Mỗi CSE cũng được xác định với
một CSE-ID duy nhất. Ví dụ về chức năng, dịch vụ được cung cấp bởi CSE bao gồm: quản lý dữ liệu, quản lý thiết bị,
quản lý đăng ký M2M. Thực thể cuối cùng là thực thể NSE (Network Service Entity) cung cấp các dịch vụ từ hạ tầng
mạng cơ sở cho các CSE.
OM2M là dự án mã nguồn mở của Eclipse, được khởi xướng bởi LAAS-CNRS được triển khai dựa trên các
chuẩn oneM2M và SmartM2M [13]. OM2M được xây dựng bằng ngôn ngữ lập trình Java sử dụng Maven và Tycho
theo kiến trúc môđun dựa trên nền tảng OSGi. OM2M cung cấp các CSE linh hoạt có thể dễ dàng triển khai trong một
mạng M2M, một thiết bị hoặc một Gateway. Mỗi CSE gồm một tập hợp các plugin khác nhau mà trong đó mỗi một
122
ĐÁNH GIÁ MÔ HÌNH BẢO MẬT CHO MẠNG VẠN VẬT DỰA TRÊN OneM2M
plugin sẽ cung cấp một chức năng cụ thể. Các plugin này có thể điều khiển cài đặt, khởi tạo, dừng, cập nhập hay xóa từ
xa mà không yêu cầu hệ thống phải khởi động lại. Vì vậy, OM2M cung cấp khả năng mở rộng thông qua các plugin và
có thể hỗ trợ các giao thức và các công nghệ khác [21]. Trong mỗi CSE có một plugin CORE là plugin chính cung cấp
một dịch vụ độc lập với các giao thức để xử lý các yêu cầu RESTful. OM2M cũng cho phép triển khai việc truyền dữ
liệu bảo mật giữa các thực thể bằng giao thức HTTPS, TLS-PSK một cách dễ dàng với plugin jetty hoặc một số plugin
khác. Bên cạnh đó, OM2M cũng hỗ trợ các thiết bị trong mạng giao tiếp với các thiết bị khác không thuộc OM2M một
cách liền mạch thông qua các proxy là IPUs (Interworking Proxy Units).
Application
AE
AE
AE
Application layer
Service layer
HTTP/CoAP/MQTT
DTLS/TLS
Mca
Mca
Mca
CSE
CSE
CSE
Mcc
Mcc
UDP/TCP
Mcn
Mcn
Mcn
NSE
Mcn
IPv4/IPv6
Underlying
Network
Underlying
Network
NSE
(IETF 6LoWPAN)
NSE
NSE
Network layer
3G/4G
IEEE 802.11 / IEEE 802.3
IEEE 802.15.4
Gateway
b)
Server
Device
a)
Hình 1. a) Chồng giao thức cho IoT theo chuẩn OneM2M, b) Kiến trúc OneM2M theo chức năng
2.2. Giao thức TLS/DTLS
TLS (Transport Layer Security) là một trong những giao thức bảo mật được dùng nhiều nhất hiện nay trong các
ứng dụng web, email, VoIP trên Internet. Tiền thân của TLS là giao thức SSL (Secure Sockets Layer) được phát triển
bởi Netscape Communications và ngày nay TLS được định nghĩa theo RFC 5246 [14]. TLS hoạt động ở tầng phiên
(thiết lập kênh truyền sử dụng mật mã bất đối xứng) và tầng trình diễn (mã hóa dữ liệu sử dụng mật mã đối xứng).
Cùng với sự phát triển về chủng loại và số lượng thiết bị IoT, những ứng dụng dựa trên nền tảng UDP ngày càng trở
nên phổ biến. Những ứng dụng này không phù hợp với TLS do một số nguyên nhân cơ bản. TLS giả thiết gói tin được
gửi trên kênh truyền ổn định, vì vậy nó không thể thực hiện bắt tay nếu một trong các gói tin bắt tay bị mất. Trong
TLS, việc giải mã bản tin N+1 phụ thuộc vào bản tin N. Sự phụ thuộc đó được được thể hiện thông qua ngữ cảnh mã
hóa (định nghĩa tại trạng thái Cipher Block Chaining) và số thứ tự được đính kèm trong mỗi bản tin (định nghĩa tại
Message Authentication Code).
DTLS (Datagram Transport Layer) được thiết kế tương tự như TLS. Tuy nhiên, nó được thiết kế để phù hợp với
ứng dụng sử dụng UDP và khắc phục các hạn chế của TLS. DTLS thiết lập bộ đếm thời gian ở cả phía máy chủ và máy
khách. Nó thực hiện gửi lại các bản tin bị mất hoặc không nhận được khi bộ đếm thời gian hết hạn. Tuy nhiên, bộ đếm
này không áp dụng với bản tin HelloVerifyRequest để tránh việc phải thiết lập trạng thái trên máy chủ. Các bản tin
trong DTLS có một thứ tự nhất định. Thứ tự này giúp máy chủ và máy khách xác định một bản tin nhận được có phải
bản tin chúng đang đợi. Nếu đúng, bản tin sẽ được xử lý. Trong trường hợp sai, bản tin sẽ được lưu lại để xử lý sau.
Bản tin TLS và DTLS có thể lớn (lên đến 224-1 byte) trong khi kích thước khung dữ liệu UDP bị giới hạn < 1500 byte.
DTLS thực hiện chia dữ liệu thành nhiều đoạn và đính kèm số thứ tự vào từng đoạn để phục vụ cho mục tiêu tổng hợp
bản tin đã bị phân mảnh.
III. MÔ HÌNH ĐỀ XUẤT
3.1. Mô hình bảo mật cho IoT dựa trên OneM2M và TLS/DTLS
Trong phần này, chúng tôi sẽ trình bày một mô hình bảo mật cho hệ thống IoT theo chuẩn oneM2M. Mô hình
được áp dụng cho các hệ thống IoT với nhiệm vụ giám sát, theo dõi, thu thập thông tin và tương tác với môi trường
thực tế thông qua các hệ thống cảm biến. Các thiết bị cảm biến này là các thiết bị hạn chế về năng lượng, khả năng tính
toán và phân bố tại các vị trí khác nhau. Trên cùng một hệ thống IoT có thể triển khai đồng thời nhiều ứng dụng tùy
theo các yêu cầu đặc thù của từng lĩnh vực. Kiến trúc tổng quan của mô hình được minh họa tại hình 2. Hệ thống sẽ
gồm ba thành phần chính theo kiến trúc chuẩn của oneM2M, phần thứ nhất là các ứng dụng chuyên biệt đầu cuối cho
người dùng. Các ứng dụng này sẽ kết nối và truy cập các tài nguyên dịch vụ được cung cấp thông qua CSE trong các
IN (Infrastructure Node) và MN (Middle Node) của hệ thống M2M bằng RESTful API. Các node này sẽ nằm trên các
máy chủ vật lý và kết nối với nhau thông qua mạng core hay Internet. Trong một hệ thống M2M sẽ chỉ có một IN đóng
vai trò máy chủ trung tâm và được kết nối đến nhiều MN máy chủ cục bộ tại các vị trí khác nhau. Phần thứ ba của hệ
thống là các thiết bị cảm biến, có nhiệm vụ thu thập thông tin, theo dõi sự thay đổi của môi trường thực tế và chuyển
chúng thành các dữ liệu số. Các cảm biến trong cùng một khu vực sẽ được kết nối với một MN để các các tài nguyên
của nó được cung cấp cho các ứng dụng hoặc người dùng đầu cuối thông qua CSE trong phạm vi mạng nội bộ và các
MN này sẽ kết nối IN để dữ liệu và tài nguyên này được cung cấp trong một phạm vi rộng rãi thông qua mạng M2M.
Nguyễn Văn Tánh, Nguyễn Gia Tuyến, Mạc Đình Hiếu, Bùi Trọng Tùng, Trần Quang Đức, Nguyễn Linh Giang
123
Tuy nhiên do các cảm biến hay các thiết bị IoT này là các thiết bị hạn chế nên chúng sẽ giao tiếp với nhau thông qua
giao thức cho mạng năng lượng thấp. Vì vậy, để các thiết bị này có thể giao tiếp với MN sẽ cần có một Gateway trung
gian ở giữa làm nhiệm vụ chuyển đổi thông điệp giữa các giao thức. Trong hình 2 cũng đặc tả chi tiết chồng giao thức
được sử dụng trong các thành phần của hệ thống. Các thiết bị IoT sử dụng giao thức IEEE 802.15.4 tại tầng PHY/MAC
cho kết nối tốc độ và năng lượng thấp và sử dụng giao thức 6LoWPAN tại tầng mạng để cho phép triển khai IPv6 trên
các thiết bị này. Mặt khác, tuy hạ tầng mạng IPv6 đã sẵn sàng triển khai trong thực tế, nhưng hiện nay mạng Internet
vẫn chủ yếu sử dụng IPv4. Chính vì vậy, để các thiết bị cảm biến có thể kết nối đến Internet và giao tiếp với các hệ
thống khác trên Internet, thì các thiết bị này sẽ kết nối với các Gateway hỗ trợ cả hai chuẩn IEEE 802.15.4 và chuẩn
Wifi (IEEE 802.11) hoặc Ethernet (IEEE 802.3), cùng cơ chế ánh xạ giữa địa chỉ IPv4 và IPv6.
OneM2M
Sensor
Applications
MN
...
Gateway
...
DTLS
Sensor
DTLS
...
IN
Internet
Sensor
Sensor
MN
Gateway
Applications
End Users
Infrastructure Node
Middle Node
Border Gateway
Sensor
Applications
TLS
Applications
Applications
TLS
Applications
DTLS
TLS
DTLS
UDP
TCP
TCP
TCP
UDP
IPv4
IPv4
IPv4
6LoWPAN
IPv4
6LoWPAN
IEEE 802.3
iEEE 802.11
IEEE 802.3
IEEE 802.11
IEEE
802.15.4
IEEE 802.3
IEEE 802.11
IEEE 802.3
IEEE 802.11
IEEE 802.15.4
Hình 2. Kiến trúc bảo mật cho hệ thống IoT theo chuẩn oneM2M
Để đảm bảo bảo mật cho hệ thống thì việc bảo mật cho quá trình truyền nhận dữ liệu hay thiết lập bảo mật đầu
cuối cho hệ thống là một yêu cầu bắt buộc. Trong mô hình bảo mật của oneM2M, giao thức TLS được sử dụng để thiết
lập kênh truyền bảo mật giữa các thực thể trong hệ thống. Tuy nhiên giao thức TLS sẽ không phù hợp cho việc truyền
nhận dữ liệu an toàn giữa các thiết bị cảm biến với các node trong oneM2M vì sự hạn chế về năng lượng, tài nguyên
tính toán của các thiết bị cảm biến. Trong mô hình này, việc thiết lập kênh truyền bảo mật giữa các thiết bị cảm biến
với các node trong mạng oneM2M sẽ dựa trên giao thức DTLS. Như đã trình bày ở trên, DTLS không được thiết kế
cho các thiết bị IoT hạn chế nên mặc dù hiện nay cũng có một công trình nghiên cứu đề xuất các cơ chế tinh chỉnh và
tối ưu DTLS cho các thiết bị IoT nhưng việc triển khai DTLS trên các thiết bị đó trong thực tế vẫn gặp rất nhiều khó
khăn, đặc biệt là khi tích hợp DTLS với các giao thức khác như CoAP, 6LoWPAN. Những vấn đề gặp phải trong quá
trình triển khai thực tế sẽ được trình bày chi tiết trong phần thực nghiệm và đánh giá.
Hình 3. Xây dựng Plugin để làm việc với giao thức DTLS
Trong phần MN của OM2M chúng tôi xây dựng một Plugin để làm việc với giao thức DTLS, mô tả được thể
hiện thông qua hình 3. Module DTLS-Client là module dùng để giao tiếp với DTLS-Server trên sensor với kênh truyền
bảo mật DTLS. Module DTLS-Client được viết bằng ngôn ngữ C, sau đó build ra file thực thi rồi đưa vào MN làm một
module trong đó. DTLS-Client có mở một TCP socket dùng để đưa dữ liệu giao tiếp với DTLS-Server ra môi trường
bên ngoài thông qua chuẩn Socket, module TCP Socket có nhiệm vụ làm cầu nối giữa OM2M với DTLS, module này
124
ĐÁNH GIÁ MÔ HÌNH BẢO MẬT CHO MẠNG VẠN VẬT DỰA TRÊN OneM2M
sẽ giao tiếp với TCP Socket Server được mở trên DTLS-Server giúp việc kết nối trở nên dễ dàng và linh hoạt. Thành
phần tiếp theo trong plugin ở MN đó là Data model, dữ liệu sau khi lấy từ DTLS-Client rồi chuyển sang TCP Socket sẽ
được chuẩn hóa theo cấu trúc đã được định nghĩa sẵn tại Data model.
3.2. Ứng dụng quản lý và theo dõi sức khỏe bênh nhận qua hệ thống cảm biến y tế dựa trên mô hình đề xuất
Trong phần này chúng tôi sẽ áp dụng mô hình để giải quyết bài toán giám sát và theo dõi sức khỏe bệnh nhân
qua hệ thống cảm biến y tế trong các bệnh viện. Sự phát triển của IoT trong những năm gần đây đã tác động mạnh mẽ
đến lĩnh vực y tế và chăm sóc sức khỏe. Các ứng dụng IoT trong dịch vụ chăm sóc sức khỏe tạo ra mô hình kết nối liền
mạch giữa bác sĩ, bệnh nhân, phòng khám và các tổ chức y khoa từ đó sẽ làm giảm chi phí vận hành, tăng cường khả
năng cung cấp các dịch vụ y tế, chăm sóc sức khỏe theo yêu cầu. Các thiết bị chăm sóc sức khỏe thông minh (smarth-
health) như các thiết bị đeo tay thông minh có tích hợp cảm biến y tế, các thiết bị y tế đo đạc chuyên dụng được tích
hợp các công nghệ kết nối không dây được đưa vào sử dụng trong thực tế hỗ trợ bác sĩ trong việc tạo hồ sơ y tế số cho
từng bệnh nhân, theo dõi các thông số sinh lý, bệnh lý theo thời gian thực để có thể phát hiện và chuẩn đoán sớm bệnh
cũng như đưa ra các phác đồ điều trị hợp lý và kịp thời đặc biệt trong các trường hợp bệnh lý có tính khẩn cấp. Tuy
nhiên một bệnh viện thường có hàng chục khoa khám chữa bệnh khác nhau với hàng trăm đến hàng nghìn giường bệnh
để đáp ứng khám và điều trị nội ngoại trú cho hàng nghìn bệnh nhân. Vì vậy, khi triển khai các thiết bị cảm biến y tế để
theo dõi tình trạng sức khỏe của bệnh nhân theo thời gian thực thì hệ thống sẽ phải đối mặt với rất nhiều thách thức như
việc có một cơ chế quản lý và vận hành hàng nghìn các thiết bị cảm biến kết nối trong mạng, cơ chế tương tác giữa bác
sĩ, bệnh nhân với các thiết bị cảm biến y tế, và đặc biệt là cơ chế bảo mật cho dữ liệu y tế vốn là loại dữ liệu nhạy cảm
và riêng tư.
Hệ thống chúng tôi đề xuất được thiết kế theo mô hình phân cấp tương ứng với mô hình hành chính phân cấp
của một bệnh viện. Sơ đồ triển khai hệ thống được minh họa tại hình 4. Trong đó hệ thống bao gồm một máy chủ trung
tâm chịu trách nhiệm quản lý cho toàn bộ bệnh viện, các tòa nhà hoặc các cơ sở tại địa điểm khác nhau sẽ có một máy
chủ khu vực chịu trách nhiệm quản lý các thiết bị được sử dụng cho cơ sở đó. Việc quản lý, kết nối giữa máy chủ trung
tâm và máy chủ khu vực sử dụng nền tảng OM2M, trong đó máy chủ trung tâm đóng vai trò IN còn các máy chủ khu
vực là MN. Trong mỗi khoa hoặc một phòng ban, sẽ có một thiết bị Gateway cho phép các thiết bị cảm biến y tế theo
chuẩn năng lượng thấp kết nối truyền nhận dữ liệu với hệ thống thông qua mạng LAN hoặc Internet. Các thiết bị này
kết nối với OM2M thông qua IPU (Interworking Proxy Unit), một proxy cho phép OM2M kết nối với các thiết bị
không thuộc OM2M. Để đảm bảo việc truyền nhận các dữ liệu y tế được bảo mật, tương tự như mô hình đề xuất ban
đầu, hệ thống sử dụng DTLS để thiết lập kênh truyền bảo mật giữa cảm biến y tế và MN và dùng giao thức TLS trong
việc kết nối và giao tiếp giữa các thực thể trong OM2M.
Bệnh viện
Tòa nhà/Cơ sở [1-n]
DTLS
Bác sĩ
Khoa/Phòng Ban [1-n]
Out of Scope
TLS
Ứng dụng quản lý
và theo dõi sức
khỏe
OM2M Platform
Thiết bị y tế
Router
mca
mca
MN
IN
TCP/UDP/IP
CSE
mcc
6LBR Gateway
802.15.4-ETH
GW
Cảm biến y tế
CSE
IPE
MN-NSE
MN-NSE
Bệnh nhân
Máy chủ khu vực
Máy chủ trung tâm
Hình 4. Kiến trúc tổng thể hệ thống theo dõi và giám sát sực khỏe bệnh nhân theo thời gian thực
IV. TRIỂN KHAI THỬ NGHIỆM VÀ ĐÁNH GIÁ
4.1. Môi trường và thiết bị triển khai thử nghiệm
Trong phần này chúng tôi sẽ tiến hành triển khai thử nghiệm hệ thống giám sát và theo dõi sức khỏe bệnh nhân
bằng cảm biến y tế theo mô hình đề xuất. Tuy nhiên phạm vi thử nghiệm của chúng tôi sẽ chỉ tập trung triển khai một
phiên bản thử nghiệm đơn giản của hệ thống để đánh giá tính khả thi của cơ chế truyền nhận dữ liệu an toàn giữa các
Nguyễn Văn Tánh, Nguyễn Gia Tuyến, Mạc Đình Hiếu, Bùi Trọng Tùng, Trần Quang Đức, Nguyễn Linh Giang
125
thiết bị cảm biến và OM2M bằng giao thức DTLS. Hệ thống triển khai thử nghiệm của chúng tôi được minh họa như
hình 5, gồm 3 thành phần chính như sau:
Bộ cảm biến y tế (Cụm a): bao gồm một cảm biến điện cơ, cảm biến ghi lại hoạt động căng trùng của cơ bắp
nối với một mạch điều khiển eHealth. eHealth là một bộ cảm biến y tế điện tử được phát triển và sản xuất bởi
Công ty Libelium [22]. Một mạch điều khiển eHealth có thể kết nối với 10 loại cảm biến y tế điện tử cầm tay
như cảm biến huyết áp, nhịp tim, lượng đường trong máu, phế dung, điện cơ, … để có thể điều khiển đo đạc
các thông số về sức khỏe của bệnh nhân một cách tự động và thu thập được các kết quả đo dưới dạng dữ liệu
số. Mạch điều khiển eHealth được kết nối với một mạch Zolertia RE-Mote để có thể truyền và nhận dữ liệu
thông qua chuẩn năng lượng thấp IEEE 802.15.4. RE-Mote [22] (vi xử lý CC2538 ARM Cortex-M3 32MHz,
Gateway (Cụm b) được tích hợp dựa trên Zolertia RE-Mote và ENC28J60. ENC28J60 hỗ trợ chuẩn RJ45,
được kết nối trực tiếp đến một Wireless Router (Cụm c) và được gán với một địa chỉ IPv4 trong mạng. Các
thiết bị trong mạng cảm biến không dây đều được gán địa chỉ IPv6. Nhiệm vụ của Gateway gồm định tuyến
trong mạng cảm biến dựa trên giao thức RPL và làm cầu nối giữa hai mạng không đồng nhất.
Thành phần IN và MN dựa trên mã nguồn mở OM2M được tích hợp tương ứng trên 2 máy tính với cấu hình
Ubuntu 16.04, vi xử lý Inter Core i5, Ram 8GB. Ứng dụng giám sát tình trạng sức khỏe được phát triển bởi
ngôn ngữ PHP và được tích hợp trên cùng máy chủ vật lý với thành phần IN.
Để thiết lập kênh truyền bảo mật giữa bộ cảm biến y tế và MN bằng giao thức DTLS, trên RE-Mote cần phải
triển khai chương trình DTLS server và tích hợp DTLS client dưới dạng một plugin trong CSE của MN. Thư viện được
sử dụng trong phần thử nghiệm là tinyDTLS [24] với phương thức bảo mật TLS_PSK_WITH_AES_128_CCM_8 và
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. Nikitin và cộng sự [25] đã đề xuất sử dụng thư viện tinyDTLS
nhưng thử nghiệm với khóa chia sẻ trước và không thể thực hiện xác thực thiết bị, vốn là yêu cầu rất quan trọng trong
các ứng dụng y tế, trong đó dữ liệu gửi về phải đảm bảo tính toàn vẹn, xác thực và độ tin cậy cao. Một số công trình
khác đề cập khóa chia sẻ trước với các phương thức như AES-CCM hoặc AES-GCM. Mặc dù đơn giản, AES-CCM và
AES-GCM đòi hỏi phải xây dựng hệ thống quản lý khóa phù hợp tại máy chủ MN.
Hình 5. Các thành phần trong hệ thống thử nghiệm
4.2. Kết quả thử nghiệm, so sánh, đánh giá và nhận xét
Bảng 1 minh họa thời gian xử lý tương ứng với từng bước của giao thức DTLS. Việc đo đạc trên MN là không
cần thiết do phân hệ này được triển khai trực tiếp trên máy tính với hiệu năng cao. Vì thế, bảng 1 chỉ đưa ra các giá trị
tương ứng với DTLS trên các thiết bị cảm biến gồm 8 bước. Trong mô hình đề xuất, thiết bị cảm biến nhận và trả lời
yêu cầu từ phân hệ MN nên đóng vai trò là máy chủ (server) trong mô hình khách/chủ. Có thể thấy, thời gian xử lý chủ
yếu tập trung vào hai bước: trao đổi khóa (ServerKeyExchange) (khoảng 20 giây) và thay đổi phương thức mã hóa
(ChangeCipherSuite) (khoảng 10 giây). DTLS sử dụng thuật toán mã hóa dựa trên đường cong Elliptic (ECC) với độ
dài khóa ngắn. Tuy nhiên, vấn đề trao đổi khóa lại dựa trên tính một chiều của hàm logarit rời rạc với một số nguyên tố
đủ lớn, nên đòi hỏi nhiều phép tính phức tạp. Bước (5) được bỏ qua do việc xác thực chữ ký số thường dẫn đến tràn bộ
nhớ RAM và khởi tạo lại toàn bộ quá trình bắt tay. Mặc dù vậy, việc gửi chứng thư của thiết bị vẫn được tiến hành tại
Bước (3) với mục tiêu đảm bảo tính toàn vẹn và xác thực của dữ liệu khi nhận được tại MN.
Bảng 1. Minh họa thời gian tính toán và xử lý được thực hiện tương ứng các bước trong quá trình bắt tay của DTLS tại thiết bị
(Đơn vị tính: miligiây)
126
ĐÁNH GIÁ MÔ HÌNH BẢO MẬT CHO MẠNG VẠN VẬT DỰA TRÊN OneM2M
Thời gian (miligiây)
Thời gian (miligiây)
(1) HelloVerifyRequest
(2) ServerHello
(3) Certificate*
2
2
3
(5) CertificateRequest*
(6) ServerHelloDone
(7) ChangeCipherSpec
(8) Finished
(Không thực hiện)
2
9.800
2
(4) ServerKeyExchange*
20.050
* Tùy chọn (có thể không cần tích hợp)
Bảng 2 đưa ra các giá trị đo liên quan bộ nhớ ROM và RAM trong trường hợp truyền thông điệp với UDP thông
thường và trường hợp có tích hợp DTLS. Rõ ràng, tích hợp DTLS khiến bộ nhớ ROM tăng khoảng 28 KB và bộ nhớ
RAM tăng khoảng 1,2 KB. Mức tăng này là chấp nhận được với thiết bị như RE-Mote (512 KB ROM và 32 KB
RAM).
Bảng 2. Bộ nhớ được sử dụng với thiết bị bình thường, thiết bị sử dụng DTLS với hai thư viện tinyDTLS và tinyECC
Thiết bị bình thường
48,8 KB
Thiết bị với DTLS
76,8 KB
ROM
RAM
11,6 KB
12,8 KB
Những phân tích ở trên là cơ sở để chúng tôi tiến hành thiết lập các thông số cài đặt và cấu hình cần thiết cho hệ
thống theo dõi sức khỏe của bệnh nhân bằng cảm biến y tế. Một trong những thông số quan trọng nhất chính là thời
gian duy trì phiên kết nối. Thời gian này hoàn toàn phụ thuộc vào thiết bị cảm biến cần sử dụng. Ví dụ, thời gian đo
nhịp thở trung bình khoảng 5 phút (trong đó 3 phút là khoảng thời gian cần thiết để thiết bị hoạt động ở trạng thái ổn
định). Đo huyết áp, phế dung, lượng đường trong máu cần 2 phút, trong khi thời gian để đo nhiệt độ cơ thể là khoảng 1
phút. Nếu so sánh với quá trình đo đạc tại thiết bị cảm biến, thì thời gian 30 giây thực hiện bắt tay (DTLS handshake)
là có thể chấp nhận được. Chúng tôi cũng tiến hành thực hiện hơn 1.000 phép đo đạc, trong đó trong một lần sẽ có 5
truy vấn được gửi đi đồng thời với 5 thiết bị khác nhau trên cùng một MN. Tỷ lệ các truy vấn được thực hiện thành
công và trả về kết quả là 100 %.
Hình 6. Kích thước gói tin khi mã hóa DTLS
Khi sử dụng DTLS thì nội dung dữ liệu y tế khi truyền trên đường truyền sẽ được mã hóa giúp cho việc bảo vệ
dữ liệu không bị lộ thông tin và không bị sửa đổi. Ví dụ thông tin đo nhiệt độ cơ thể gửi đi là 32,80.
Nguyễn Văn Tánh, Nguyễn Gia Tuyến, Mạc Đình Hiếu, Bùi Trọng Tùng, Trần Quang Đức, Nguyễn Linh Giang
127
Hình 7. Kết quả giám sát thông tin trên môi trường truyền tải sử dụng cơ chế bảo mật DTLS
Nội dung dữ liệu đã được mã hóa thành 22 bytes và dữ liệu sau khi được mã hóa sẽ không thể đọc hiểu được.
Phương thức mã hóa sử dụng là TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 như được mô tả trong hình 7.
Với kịch bản không sử dụng DTLS mà chỉ sử dụng thuần UDP thì qua wireshare ta có thể thấy rằng dữ liệu
không được mã hóa và có thể dễ dàng đọc hiểu và khai thác được, hơn nữa vì không có cơ chế bảo vệ nên sẽ dễ dàng bị
giả mạo. Ngoài ra ta có thể thấy là khi không mã hóa thì kích thước payload của phần dữ liệu là 6 bytes.
Mặc dù đạt được kết quả khả quan, mô hình đề xuất vẫn tồn tại một số hạn chế. Thứ nhất, nó chưa thể xây dựng
được CoAP trên tầng ứng dụng. CoAP khi tích hợp với DTLS thường dẫn đến tràn bộ nhớ RAM, dù đã được triển khai
trên thiết bị RE-Mote (32KB RAM). Do đó không thể đảm bảo được đường truyền bảo mật thông suốt end-to-end giữa
người dùng và thiết bị cảm biến đầu cuối. Thứ hai, DTLS chỉ thực sự phù hợp với các thiết bị có cấu hình tương tự như
RE-Mote. Nó không thể tích hợp trên mạch khác như Zolertia Z1 hoặc Micaz (vi xử lý MSP430 8-16 MHz, 96KB
ROM, 8KB RAM). Giá thành của RE-Mote cao (≥100 USD/thiết bị) sẽ khiến cho việc triển khai mở rộng hệ thống gặp
nhiều khó khăn, thách thức.
V. KẾT LUẬN
Bài báo thực hiện đánh giá mô hình bảo mật cho mạng vạn vật dựa trên chuẩn oneM2M. Trong đó chúng tôi tập
trung vào hai nội dung chính là triển khai mô hình trong một ngữ cảnh thực tế là hệ thống giám sát và theo dõi sức
khỏe bệnh nhân bằng cảm biến y tế đồng thời triển khai hệ thống thử nghiệm đơn giản bằng các thiết bị phần cứng IoT
phổ biến hiện nay. Chúng tôi tiến hành đánh giá tính khả thi việc đảm bảo an toàn cho quá trình truyền nhận dữ liệu
giữa các thiết bị cảm biến không đồng nhất thông qua thử nghiệm điều khiển các thiết bị đo đạc thu thập các thông số
sức khỏe qua nền tảng OM2M với giao thức bảo mật là TLS và DTLS. Các kết quả thử nghiệm chỉ ra rằng tuy có thể
triển khai giao thức DTLS trên các thiết bị IoT nhưng vẫn còn tồn tại rất nhiều hạn chế như không thể tích hợp đồng
thời giao thức tầng ứng dụng (CoAP), thời gian kết nối truyền nhận dữ liệu vẫn có một độ trễ nhất định. Bên cạnh đó,
chi phí của các thiết bị phần cứng đáp ứng được yêu cầu của DTLS cũng tạo ra rào cản trong việc triển khai hệ thống
một cách rộng rãi.
VI. LỜI CẢM ƠN
Các nghiên cứu trong bài báo này được hỗ trợ của đề tài Nghị định thư năm 2016-2018 “Xây dựng kiến trúc hạ
tầng an toàn thông tin cho mạng vạn vật trên nền điện toán đám mây” mã số NĐT.14.TW/16.
VII. TÀI LIỆU THAM KHẢO
[1] Stergiou, Christos, et al. "Secure integration of IoT and cloud computing". Future Generation Computer
Systems 78 (2018): 964-975.
[2] Singh, Vaibhav Pratap, et al. "IoT standardization efforts-An analysis". Smart Technologies For Smart Nation
(SmartTechCon), 2017 International Conference On. IEEE, 2017.
[3] Ammar, Mahmoud, Giovanni Russello, and Bruno Crispo. "Internet of Things: A survey on the security of IoT
frameworks". Journal of Information Security and Applications 38 (2018): 8-27.
[4] Borgia, Eleonora. "The Internet of Things vision: Key features, applications and open issues". Computer
Communications 54 (2014): 1-31.
[5] Da Xu, Li, Wu He, and Shancang Li. "Internet of things in industries: A survey". IEEE Transactions on industrial
informatics 10.4 (2014): 2233-2243.
[6] Khan, Minhaj Ahmad, and Khaled Salah. "IoT security: Review, blockchain solutions, and open
challenges". Future Generation Computer Systems (2017).
128
ĐÁNH GIÁ MÔ HÌNH BẢO MẬT CHO MẠNG VẠN VẬT DỰA TRÊN OneM2M
[7] "http://www.onem2m.org", accessed on 10th June, 2018.
[8] Alaya, M. Ben, et al. "OM2M: Extensible ETSI-compliant M2M service platform with self-configuration
capability". Procedia Computer Science 32 (2014): 1079-1086.
[9] IEEE, IeEEE Standard for Local and metropolitan networks–Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs), 2012. URL https://standards.ieee.org/findstds/standard/802.15.4-2011.html.
[10]Shelby, Zach, and Carsten Bormann. 6LoWPAN: The wireless embedded Internet. Vol. 43. John Wiley & Sons,
2011.
[11]Shelby, Zach, Klaus Hartke, and Carsten Bormann. "The constrained application protocol (CoAP)." (2014).
[12]Hunkeler, Urs, Hong Linh Truong, and Andy Stanford-Clark. "MQTT-S-A publish/subscribe protocol for Wireless
Sensor Networks". Communication systems software and middleware and workshops, 2008. comsware 2008. 3rd
international conference on. IEEE, 2008.
[14]T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed
Standard), August 2008. http://www.ietf.org/rfc/rfc5246.txt.
[15]Rescorla, Eric, and Nagendra Modadugu. "Datagram transport layer security version 1.2". (2012).
[16]Raza, Shahid, Daniele Trabalza, and Thiemo Voigt. "6LoWPAN compressed DTLS for CoAP". Distributed
Computing in Sensor Systems (DCOSS), 2012 IEEE 8th International Conference on. IEEE, 2012.
[17]Haroon, Asma, et al. "E-Lithe: A Lightweight Secure DTLS for IoT". Vehicular Technology Conference (VTC-
Fall), 2017 IEEE 86th. IEEE, 2017.
[18]Perelman, Vladislav. "Security in IPv6-enabled wireless sensor networks: An implementation of TLS/DTLS for
the Contiki operating system". PhD diss., MSc Thesis, Jacobs University Bremen (2012).
[19]Glissa, Ghada, and Aref Meddeb. "6LowPSec: An End-to-End Security Protocol for 6LoWPAN". Ad Hoc
Networks (2018).
[20]Diogo, Pedro, Nuno Vasco Lopes, and Luis Paulo Reis. "An ideal IoT solution for real-time web
monitoring". Cluster Computing 20.3 (2017): 2193-2209.
[21]Sicari, Sabrina, et al. "Secure OM2M service platform". Autonomic Computing (ICAC), 2015 IEEE International
Conference on. IEEE, 2015.
[24]Bergmann, Olaf. "TinyDTLS". Web page: http://tinydtls. sourceforge. net/. Visited (2013): 02-15.
[25]Nikitin, Kirill. "DTLS Adaptation for Efficient Secure Group Communication". (2015).
REVIEW THE SECURITY MODEL FOR INTERNET OF THINGS (IOT) WITH OneM2M
Nguyen Van Tanh, Nguyen Gia Tuyen, Mac Dinh Hieu, Bui Trong Tung, Tran Quang Duc, Nguyen Linh Giang
ABSTRACT: The Internet of Things is being used extensively in life from industrial activities, automation, environmental
monitoring, transportation to life support systems such as smart homes, smart city, supervision and health care, etc. Besides the
tremendous benefits, IoT also has many challenges such as the variety and complexity of connectivity standards, heterogeneity
hardware, software, communication mechanisms of IoT equipment in the network infrastructure. Traditional security models and
solutions are no longer relevant and effective with IOT network infrastructure. In this paper, we introduce a security model for the
OneM2M-based network and propose a model in a real-time monitoring system supporting patient monitoring with a sensor system
medical. We also implemented a simple test version of the above system in a realistic environment to evaluate the feasibility of
secure data transmission between medical sensors and OM2M systems, DTLS protocol. The experimental results of the system will
in fact show the effectiveness of the proposed model as well as the challenges that need to be addressed…
Keyword: IoT, oneM2M, DTLS, OM2M, Security for IoT.
9 trang
17600
Free
Bạn đang xem tài liệu "Đánh giá mô hình bảo mật cho mạng vạn vật dựa trên OneM2M", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- danh_gia_mo_hinh_bao_mat_cho_mang_van_vat_dua_tren_onem2m.pdf
