Luận văn thạc sĩ Kỹ thuật viễn thông: Thiết kế và triển khai framework bảo mật đa lớp cho mạng 6lowpan/ipv6

GIỚI THIỆU

TỔNG QUAN

Internet of Things (IOT) – là từ khóa đang ngày càng phổ biến trên thế giới, là xu hướng đang được các doanh nghiệp trong mọi lĩnh vực quan tâm và đầu tư nghiên cứu Cuộc đua nghiên cứu, tìm tòi, phát triển về “kết nối vạn vật” đang tăng một cách chóng mặt trong thị trường trong và ngoài nước Đặc biệt hơn, khi con người đang tìm đến những công nghệ giúp họ tận hưởng những tiện nghi tốt nhất trong ngôi nhà của chính mình, và từ đó thuật ngữ “Smart Home” (còn được gọi là Home Automation) được ra đời

Theo một phân tích dự đoán của trang phân tích dataprot.net: thiết bị IOT dành cho người tiêu dùng sẽ thống trị trong năm 2021 với hơn 21 tỷ thiết bị được lắp đặt, dành cho công nghiệp là khoảng 3,17 tỷ Và sẽ tăng lên thành 25.4 tỷ thiết bị vào năm 2030, ngoài ra trang này cũng đưa ra một tính toán là sẽ có 152,200 thiết bị IOT kết nối với Internet mỗi phút Các thiết bị IOT hiện nay được phân bổ rộng trên nhiều lĩnh vực: Với các thiết bị dành cho người dùng phổ thông, được xem là động lực tăng trưởng chính của IOT hiện nay, với khoảng 5.2 tỷ thiết bị trong năm 2017, và đã tăng lên 11,19 tỷ thiết bị vào năm 2018 Với người tiêu dùng, loại thiết bị chính là phương tiện giao thông (xe ô tô), smartTV và các loại set-top box kỹ thuật số Với các thiết bị dành cho doanh nghiệp, các thiết bị như camera an ninh, hệ thống đo lượng điện tiêu thụ thông minh cũng gia tăng đáng kể về số lượng

Trong tương lai, IOT tập trung vào các dịch vụ sản phẩm trong nhà (Connected Home), tích hợp vào hệ thống công nghệ thông tin và công nghê vận hành có sẵn (IT/OT Intergration) để nâng cao chất lượng quản lý và năng suất lao động Học máy thống kệ, học dữ liệu, thuật toán phân tích và dự báo thông minh đang được IoT dựa vào để phụ vụ các nhu cầu khác nhau Hai sản phẩm điển hình là Google Nest và Amazon Echo (Alexa) Các công ty lớn trong ngành cũng đã và đang đẩy mạnh đầu tư, xây dựng hệ sinh thái cho riêng mình và nghiên cứu để tạo ra các sản phẩm IoT mới

Một vấn đề bên cạnh sự phát triển rầm rộ của các thiết bị IOT, đó là vấn đề bảo mật Các khía cạnh bảo mật cần được quan tâm liên quan tới xác minh chủ thiết bị, an toàn khi truyền- nhận tin giữa chủ thiết bị tới thiết bị, an toàn khi truyền-nhận tin giữa các thiết bị với nhau… Khi các thiết bị được sử dụng nhiều hơn, người dùng không quá để tâm đến các vấn đề bảo mật, chỉ gần như chú trọng tới sự thuận tiện mà các thiết bị này đem lại, việc này sẽ trở thành miếng mồi ngon, miền đất hứa cho những hacker, tin tặc, kẻ xấu xâm phạm, chiếm quyền điều khiển các thiết bị này, gây khó khăn cho người dùng, phá hoại, làm trò tiêu khiển, nhưng nguy hiểm hơn, đó là đánh cắp, chiếm đoạt các thông tin nhạy cảm của chủ thiết bị (thông tin cá nhân, thông tin ngân hàng,…) Để tiếp cận và bắt kịp các xu hướng, vấn đề bảo mật trên, với sự hướng dẫn của TS Võ Quế Sơn – giảng viên bộ môn viễn thông, em quyết định đi đến đề tài luận văn với tên “Thiết Kế

Và Triển Khai Framework Bảo Mật Đa Lớp Cho Mạng 6lowpan/Ipv6”.

NHIỆM VỤ LUẬN VĂN

Với những vấn đề bảo mật đáng chú ý khi sự nở rộ các thiết bị IOT trong cuộc sống con người hiện nay, thì việc nghiên cứu các phương pháp bảo mật trên mạng 6LoWPAN được sử dụng trên các hệ thống các thiết bị IOT, được xem là cấp thiết, khả thi và theo kịp xu hướng IOT ít nhất là ở Việt Nam Dưới đây là nhiệm vụ đặt ra và hướng giải quyết của đề tài luận văn này

1.2.1 Nhiệm vụ của đề tài

Nhiệm vụ chính của luận văn là tìm hiểu các lỗ hổng, các dạng tấn công của tin tặc, hacker sẽ sử dụng để tấn công vào hệ thống IOT hiện nay, từ đó sẽ đo đạc, thiết kế, chạy thử nghiệm các phương pháp phòng ngự lại các kiểu tấn công này, sau đó ghi nhận lại kết quả khi chạy mô phỏng, thực tế

Các nhiệm vụ được chia nhỏ như sau:

 Nắm rõ các giao thức ngăn xếp/lớp được phát triển trong hệ điều hành Contiki OS (bao gồm các lớp sau: Physical, Link, Network, Transport, Application và lớp AdaptiveSec - lớp bảo mật), đặc biệt là các giao thức của 6LoWPAN/IPv6 được tích hợp trong Lớp Network của Contiki OS

 Nghiên cứu các phương pháp tấn công vào hệ thống IOT hiện nay: Denial-of-Sleep Attack (HELLO Flood Attack, Yo-Yo Attack, Hidden Wormhole Attack)

 Nghiên cứu các phương pháp bảo mật đa lớp (lớp application và lớp link) để ngăn chặn, hạn chế các tấn công trên

 Triển khai hệ thống, ghi nhận kết quả được mô phỏng trên phần mềm Cooja Simulator

 Triển khai hệ thống, ghi nhận kết quả trên thiết bi thực tế

1.2.2 Giới hạn của đề tài

Hệ thống được mô phỏng với số lượng các node tham gia lớn, từ đó phần mềm yêu cầu phần cứng cao, do hạn chế về phần cứng (chỉ sử dụng laptop cấu hình tầm trung) nên kết quả được ghi nhận phần mềm mô phỏng với thời gian hoạt động ngắn Ngoài ra cũng hạn chế về thiết bị thực tế, nên chỉ triển khai hệ thống trên một mô hình nhỏ, số lượng ít

Các nội dung cần thực hiện để hoàn thành đề tài luận văn bao gồm các công việc sau:

Nội dung 1: Tìm hiểu lý thuyết mạng cảm biến không dây, cấu trúc và các ứng dụng xung quanh Ở nội dung này, em sẽ tìm hiểu về mạng cảm biến không dây, các chuẩn giao tiếp chính hiện nay, mô hình mạng và các ứng dụng hiện nay để có cái nhìn tổng quan để tiến hành thực hiện đề tài này

Nội dung 2: Nghiên cứu Contiki OS bao gồm các lớp trong Contiki OS, các chuẩn giao thức của mạng 6LoWPAN, bảo mật

Contiki OS bao gồm rất nhiều giao thức và ngăn xếp/lớp khác nhau (theo mô hình OSI) trong đó nổi bật là giao thức 6LoWPAN/IPv6 mà em hướng đến, ngoài ra còn bảo mật cho mạng 6LoWPAN/IPv6

Nội dung 3: Nghiên cứu về các phương pháp tấn công Denial-of-Sleep

Tìm hiểu cách thức, cơ chế tấn công Denial-of-sleep (còn được gọi là từ chối ngủ) tác động lên các node trong mạng, làm cho chúng không thể “ngủ” khi không hoạt động, từ đó làm tiêu tốn nhiều năng lượng

Nội dung 4: Nghiên cứu về các phương pháp phòng thủ ở lớp application và lớp link

Từ việc phân tích cuộc tấn công ở trên, em sẽ tìm hiểu các phương pháp phòng thủ, làm hạn chế đi sự nguy hiểm mà cuộc tấn công đó đem lại

Nội dung 5: Tiến hành mô phỏng, đo đạc các thông số, và chạy trên thiết bị thực tế

Chạy demo mô phỏng trên phần mềm Cooja, để kiểm nghiệm sự hiệu quả của các phương pháp phòng thủ Từ đó chạy thực tế trên phần cứng để xác minh kết quả, cũng như kiểm tra các sai số nếu có giữa giữa môi trường thử nghiệm và môi trường thực tế

Nội dung 6: Viết báo cáo, chuẩn bị slide thuyết trình

CƠ SỞ LÝ THUYẾT

TỔNG QUAN VỀ MẠNG CẢM BIẾT KHÔNG DÂY

2.1.1 Giới thiệu mạng cảm biến không dây

Trong những năm gần đây, rất nhiều mạng cảm biến không dây đã và đang được triển khai cho nhiều ứng dụng khác nhau: theo dõi sự thay đổi của môi trường, khí hậu, chuẩn đoán sự hỏng hóc của máy móc, thiết bị, theo dấu và giám sát các bệnh nhân, quản lý thuốc trong các bệnh viên, quản lý kho hàng, theo dõi và điều khiển giao thông, các phương tiện xe cộ Hơn nữa với sự tiến bộ công nghệ gần đây và hội tụ của hệ thống các công nghệ như kỹ thuật vi điện tử, công nghệ nano, giao tiếp không dây, công nghệ mạch tích hợp, vi mạch phần cảm biến, xử lý và tính toán tín hiệu, đã tạo ra những con cảm biến có kích thước nhỏ, đa chức năng, giá thành thấp, công suất tiêu thụ thấp, làm tăng khả năng ứng dụng rộng rãi của mạng cảm biến không dây

Một mạng cảm biến không dây là một mạng bao gồm nhiều nút cảm biến nhỏ có giá thành thấp, và tiêu thụ năng lượng ít, giao tiếp thông qua các kết nối không dây, có nhiệm vụ cảm nhận, đo đạc, tính toán nhằm mục đích thu thập dữ liệu để đưa ra các quyết định về môi trường xung quanh Một trong những đặc điểm quan trọng là sự giới hạn về năng lượng của chúng Các nút cảm biến này yêu cầu tiêu thụ công suất thấp Các nút cảm biến hoạt động có giới hạn và nói chung là không thể thay thế được nguồn cung cấp Do đó, trong khi mạng truyền thông tập trung vào đạt được các dịch vụ chất lượng cao, thì các giao thức mạng cảm biến phải tập trung đầu tiên vào bảo toàn công suất

Mạng cảm biến có một số đặc điểm sau:

 Có khả năng tự tổ chức, yêu cầu ít hoặc không có sự can thiệp của con người

 Truyền thông tin cậy, quảng bá trong phạm vi hẹp và định tuyến multihop

 Triển khai dày đặc và khả năng kết hợp giữa các nút cảm biến

 Giới hạn về mặt năng lượng, công suất phát, bộ nhớ và công suất tính toán

Chính những đặc tính này đã đưa ra những yêu cầu thay đổi trong thiết kế mạng cảm biến

2.1.2 Cấu trúc mạng cảm biến không dây

2.1.2.1 Tổng quan cấu trúc mạng cảm biến không dây

Trong hệ thống mạng cảm biến không dây có các trạm gốc và trung tâm điều khiển Trạm gốc đóng vai trò cổng kết nối giữa nút mạng và trung tâm điều khiển, tiếp nhận thông tin của các nút mạng và chuyển tới trung tâm điều khiển qua nhiều cách khác nhau Các nút mạng truyền tin theo kiểu nhiều chặng, từ nút mạng này sang nút mạng khác và về trạm gốc

Từ trạm gốc có thể gửi thông tin cho người sử dụng (trung tâm điều khiển) theo nhiều cách như trực tiếp qua hệ thống máy tính, qua mạng Internet, qua vệ tinh nhờ đó người giám sát có thể nhận được thông tin dù đang ở bất cứ đâu

Hình 2.1 Tổng quan mạng cảm biến không dây

2.1.2.2 Giới thiệu về nút cảm biến

Mỗi nút cảm biến được cấu thành bởi 4 thành phần cơ bản như ở Hình 2.2 đơn vị cảm biến (a sensing unit), đơn vị xử lý (a processing unit), đơn vị truyền dẫn (a transceiver unit) và bộ nguồn (a power unit) Ngoài ra có thể có thêm những thành phần khác tùy thuộc vào từng ứng dụng

Hình 2.2 Cấu tạo nút cảm biến

Các đơn vị cảm biến (sensing units) bao gồm cảm biến và bộ chuyển đổi tương tự-số Dựa trên những hiện tượng quan sát được, tín hiệu tương tự tạo ra bởi sensor được chuyển sang tín hiệu số bằng bộ ADC, sau đó được đưa vào bộ xử lý Đơn vị xử lý thường được kết hợp với bộ lưu trữ nhỏ (storage unit), quyết định các thủ tục làm cho các nút kết hợp với nhau để thực hiện các nhiệm vụ định sẵn Phần thu phát vô tuyến kết nối các nút vào mạng

Hầu hết các kĩ thuật định tuyến và các nhiệm vụ cảm biến của mạng đều yêu cầu có độ chính xác cao về vị trí Các bộ phận di động đôi lúc cần phải dịch chuyển các nút cảm biến khi cần thiết để thực hiện các nhiệm vụ đã ấn định Tất cả những thành phần này cần phải phù hợp với kích cỡ từng module Ngoài kích cỡ ra các nút cảm biến có một số ràng buộc nghiêm ngặt khác, như là: phải tiêu thụ rất ít năng lượng, hoạt động ở mật độ cao, có giá thành thấp, có thể tự hoạt động, và thích biến với sự biến đổi của môi trường

2.1.2.3 Đặc điểm của cấu trúc mạng cảm biến không đây

Như trên ta đã biết đặc điểm của mạng cảm biến là bao gồm một số lượng lớn các nút cảm biến, các nút cảm biến có giới hạn và ràng buộc về tài nguyên đặc biệt là năng lượng rất khắt khe Sau đây ta sẽ phân tích một số đặc điểm nổi bật trong mạng cảm biến như sau:

 Chi phí thấp: trong mạng cảm biến không dây thường là hàng trăm hoặc hàng ngàn các nút cảm biến được triển khai để đo bất kỳ môi trường vật lý nào Để giảm tổng chi phí của toàn bộ mạng lưới chi phí của nút cảm biến phải được giữ ở mức khả thi

 Năng lượng hiệu quả: Năng lượng trong mạng cảm biến không dây được sử dụng cho các mục đích khác nhau mục đích như tính toán, truyền thông và lưu trữ Nút cảm biến tiêu thụ năng lượng nhiều hơn so với bất kỳ giao tiếp khác Vì thế,các giao thức và sự phát triển thuật toán nên xem xét tiêu thụ điện năng trong giai đoạn thiết kế

 Công suất tính toán: bình thường nút có giới hạn tính toán như chi phí và năng lượng cần phải được xem xét

 Khả năng truyền thông: mạng cảm biến không dây thường giao tiếp sử dụng sóng vô tuyến qua một kênh không dây Nó có thể giao tiếp trong phạm vi ngắn, hẹp và băng thông rộng Kênh truyền thông có thể là hai chiều hoặc đơn hướng Với những người không được giám sát và thù địch môi trường vận hành thì rất khó chạy mạng cảm biến không dây trơn tru.Vì vậy, phần cứng và phần mềm để truyền thông phải có để xem xét tính mạnh mẽ, an ninh và khả năng phục hồi

 An ninh và Bảo mật: Mỗi nút cảm biến phải có cơ chế bảo mật đủ để ngăn chặn truy cập trái phép, tấn công, và thiệt hại không chủ ý của thông tin bên trong nút cảm biến

 Phân biệt cảm biến và xử lý: số lượng lớn nút cảm biến được phân phối thống nhất hoặc ngẫu nhiên mạng cảm biến không dây mỗi node có khả năng thu thập, phân loại, xử lý, tập hợp và gửi dữ liệu đến bộ thu nhận (sink) Vì vậy phân phối cảm nhận cung cấp sự vững mạnh cho hệ thống

2.1.2.4 Kiến trúc giao thức của mạng cảm nhận không dây

Kiến trúc giao thức cảm biến không dây bao gồm: Lớp vật lý, lớp liên kết dữ liệu, lớp mạng, lớp truyền tải, lớp ứng dụng, phần quản lý công suất, phần quản lý di động và phần quản lý nhiệm vụ Lớp vật lý cung cấp các kỹ thuật điều chế, phát và thu Tại lớp liên kết dữ liệu, giao thức điều khiển truy cập môi trường (MAC) phải tối ưu sử dụng năng lượng và có khả năng giảm thiểu xung đột giữa các nút mạng khi truy cập môi trường Thiết kế giao thức MAC là rất quan trọng vì nó quyết định nhiều đến việc tiêu thụ năng lượng các nút mạng Lớp mạng đảm bảo các hoạt động định tuyến số liệu được cung cấp bởi lớp truyền tải Lớp truyền tải giúp duy trì luồng số liệu nếu ứng dụng mạng cảm biến yêu cầu Tùy theo nhiệm vụ cảm biến, các loại phần mềm khác nhau có thể được xây dựng và sử dụng ở lớp ứng dụng

Ngoài ra, các phần quản lý công suất, di chuyển và nhiệm vụ sẽ giám sát việc sử dụng công suất, sự di chuyển và thực hiện nhiệm vụ giữa các nút cảm nhận Những phần này giúp các nút cảm nhận phân phối nhiệm vụ cảm biến và tiêu thụ năng lượng tổng thể thấp hơn

Hình 2.3 Kiến trúc giao thức mạng cảm biến không dây

CÁC CƠ CHẾ BẢO MẬT CHO 6LOWPAN

Những hạn chế của các phương pháp bảo mật 6loWPAN hiện nay

Hiện nay giao thức 6loWPAN đang được bảo mật và an toàn dựa trên 802.15.4 security sublayer để loại bỏ các khung tin tấn công hoặc phát lại bằng việc thêm vào trong khung tin mã xác thực thông điệp (MIC - Message Integrity Code) và số đếm khung (frame counter), ngoài ra các khung tin còn được mã hóa bởi một key chung Tuy vậy, những thực thi này bộc lộ ra nhiều điểm hạn chế mà kẻ tấn công có thể khai thác

Hình 3.1 Khung tin 6loWPAN truyền thống Nguồn [4]

Cơ chế tham gia mạng 6LoWPAN còn phụ thuộc vào lớp Network nơi giao thức RPL lấy nút chịu trách nhiệm root trong mạng làm chủ, nắm quyền do đó các nút con chỉ quan tâm đến nút chủ đó mà không quan tâm đến hàng xóm của mình (các nút cũng chịu root bởi nút chủ), khi không có cơ chế xác thực các hàng xóm của mình thì việc kẻ tấn công giả dạng rồi lấy gói hay "tiêm" các gói làm nghẽn mạng rất dễ xảy ra

Việc sử dụng key chung cho toàn mạng không an toàn vì khi đã được tham gia vào mạng ở lớp Network thì việc trích ra trong các gói tin trao đổi hoàn toàn có thể xảy ra [34]

Ngoài ra còn có một phương pháp là mỗi mỗi nút mạng mỗi key Điều này không thực tế vì nếu nút mạng dày đặc, mỗi nút phải lưu toàn bộ các thông tin sau: key (ít nhất 16bytes), frame counter (từ 2-4bytes) chính việc này đã không phù hợp với bộ nhớ cực kì hạn chế của mạng 6LoWPAN

Sử dụng frame counter không có cơ chế xử lý khi node bị reboot (hết pin, lỗi stack, v.v ) hoặc rời khỏi mạng nên dễ dàng khai thác khi kẻ tấn công có thể phát lại những khung tin trước đó Hơn nữa frame counter chỉ để dành cho có khung tin unicast mà gói tin broadcast không thể sử dụng điều này

Vì chính những điều này mà lớp mới ra đời thay cho 802.15.4 security sublayer truyền thống: The link-layer security sublayer và Adaptive Security Later Các lớp này vẫn nằm giữa 2 lớp Link layer và Network layer nhưng mang nhiều ưu điểm hơn, khắc phục hạn chế được nêu ra ở trên, hơn nữa vẫn liên tục cập nhật các giao thức bảo mật mới được phát triển bởi các nhà phát triển Những phần tiếp sau đây ta sẽ tìm hiểu các phương pháp bảo mật được sử dụng trong mạng 6LoWPAN ở lớp Adaptive Security và The Link-Layer Security Sublayer

The Link-Layer Security Sublayer

Ở phần này ta sẽ tìm hiểu lớp LLSEC qua các giao thức, chương trình trao đổi key đôi (pairwise key) ngẫu nhiên giữa các hàng xóm với nhau cũng như qui định các khung tin unicast, broadcast để đảm bảo xác thực cho mạng 6LoWPAN, khắc phục những hạn chế của bảo mật truyền thống mà phù hợp với những tính chất đặc trưng của mạng năng lượng thấp Trong đó ta cần tìm hiểu 2 "scheme" được "plug-in" vào APKES phổ biến hiện nay để chia sẻ an toàn bí mật của các khóa đuọc load trước trong mạng là LEAP, Fully Pairwise Keys scheme, Random scheme và Blom’s scheme

 Pluggable Schemes sử dụng trong APKES a) Localized Encryption and Authentication Protocol (LEAP) Ở LEAP, các nút mạng trước hết cần phải load trước Km - master key và ngay sau khi hình thành pairwise key thì xóa master key này đi Ví dụ nút u chưa hình thành pairwise key và vẫn còn giữ Km, khi đó u sẽ tạo ra một số bí mật riêng Ku từ Km là Ku = F(Km, IDu) với F

23 là hàm giả ngẫu nhiên từ seed Km và input là IDu IDu chính là địa chỉ duy nhất của u trong mạng Lúc tạo Ku xong, u sẽ broadcast HELLO với kịch bản như sau u -> * : HELLO < 𝐼𝐷 𝑢 > v -> u : ACK < 𝐼𝐷 𝑣 , 𝐼𝐷 𝑢 >, 𝐾 𝑢

Khi đó, hàm xóm v nhận được gói tin thì trả lại ACK cho u Gói tin ACK này được xác thực bằng MIC được tạo từ 𝐾 𝑣 (là khóa ngẫu nhiên tạo từ 𝐾 𝑚 qua hàm giả ngẫu nhiên) Nhờ vào việc trích được 𝐼𝐷 𝑣 trong gói tin mà u lấy được từ ACK, u tạo ra 𝐾 𝑣 nhờ 𝐾 𝑚 qua hàm giả ngẫu và so sánh xem có đúng với MIC được đính kèm hay không, nếu đúng thì lúc này u sẽ tạo ra pairwise key là 𝐾 𝑢,𝑣 = F(𝐾 𝑣 , 𝐼𝐷 𝑢 ) và ngay sau đó xóa master key 𝐾 𝑚 đi Bên cạnh đó v cũng tạo ra 𝐾 𝑣,𝑢 từ 𝐾 𝑢 và 𝐼𝐷 𝑣 qua hàm giả ngẫu

Hạn chế của phương pháp này là ở đây v vẫn tạo ra pairwise key 𝐾 𝑣,𝑢 mặc dù chưa xác thực u nên APKES đã thêm tính năng xác thực 2 chiều vào để khắc phục b) Blom’s Scheme

Với việc sử dụng và load trước nhiều thông số hơn LEAP như λ, n, l hay các ma trận D, G cũng như các ràng buộc của chúng thì việc tạo ra key từ các ma trận nhưng hiệu quả mang lại không cao khi tốn tài nguyên tính toán, flash memory cũng như RAM tỉ lệ với các thông số trên

Hình 3.2 Blom’s scheme Nguồn [4] c) Fully Pairwise Keys Scheme

Một lược đồ đơn giản khác là lược đồ các khóa theo cặp đầy đủ, trong đó mỗi nút được tải trước một khóa theo cặp để giao tiếp với bất kỳ nút nào khác Đây là sự thỏa hiệp có khả năng phục hồi cao hơn, nhưng vẫn còn ba vấn đề:

1 Đầu tiên, lược đồ các khóa ghép nối đầy đủ có thể quá tiêu tốn bộ nhớ cho các mạng 6LoWPAN quy mô lớn Ví dụ: khi sử dụng các khóa 128 bit trong mạng 32.768 nút, mỗi nút phải lưu trữ 500KB (≈ 32, 767 × 16 byte) các khóa theo cặp Đây đã là một nửa tổng dung lượng bộ nhớ flash ngoài trên một mote TelosB - một nút điển hình Ngoài ra, để hỗ trợ việc bổ sung các nút mới trong thời gian chạy, mỗi nút cần lưu trữ một khóa ghép nối để liên lạc với mỗi nút chưa được triển khai Có thể tải trước ít khóa ghép nối hơn nếu các nút lân cận của nút được biết trước, nhưng điều này sẽ làm phức tạp việc triển khai

2 Thứ hai, có một vấn đề liên quan đến việc quản lý các bộ đếm khung Để phát hiện các khung được phát lại, bộ đếm khung gần đây nhất trên mỗi địa chỉ nguồn cần được lưu trữ Việc xóa bộ đếm khung hình khi một nút biến mất là không thể vì kẻ tấn công sau đó có thể phát lại các khung hình cũ Do đó, theo thời gian, không phải tất cả các bộ đếm khung hình đều sẽ phù hợp với bộ nhớ truy cập ngẫu nhiên giới hạn (RAM) trên các nút, mà một số bộ đếm cần được hoán đổi sang bộ nhớ flash ngoài, điều này tiêu tốn năng lượng

3 Thứ ba, trong khi các khóa ghép nối cung cấp một giải pháp có khả năng phục hồi thỏa hiệp để đảm bảo các khung hình đơn, không có giải pháp nào như vậy cho các khung hình quảng bá Các khung phát sóng phải được xác thực bằng các khóa được chia sẻ giữa các nút lân cận Do đó, một sự thỏa hiệp nút không chỉ tiết lộ một khóa quảng bá duy nhất, mà còn cả những khóa của các nút lân cận Đây là vấn đề khi cố gắng phát hiện các nút bị xâm phạm vì khung phát sóng xác thực độc hại có thể giả vờ bắt nguồn từ một nút không bị xâm phạm d) Random Scheme

Nhớ lại rằng trong lược đồ các khóa theo cặp đầy đủ, mỗi nút được tải trước bằng một khóa theo cặp để giao tiếp với bất kỳ nút nào khác Ngược lại, trong lược đồ các khóa theo cặp ngẫu nhiên, chỉ một số cặp nút có các khóa theo cặp Ví dụ, trong mạng 10.000 nút, mỗi nút

25 chỉ phải lưu trữ 75 khóa ghép nối để đạt được xác suất 0,5 để có một khóa ghép nối với nút khác Lý do tương tự như nghịch lý ngày sinh Hơn nữa, nếu mỗi nút có ít nhất 20 hàng xóm, mạng được kết nối với xác suất 0,99999 Hai nút không có khóa ghép nối phải sử dụng nút trung gian để thiết lập khóa đường dẫn Qua đó, nút trung gian không may học được khóa đường dẫn đã thiết lập Để giảm thiểu vấn đề này, có thể sử dụng nhiều bên trung gian

 Adaptable Pairwise Key Establishment Scheme (APKES)

APKES là chương trình hình thành pairwise key (được tạo một cách random) giữa 2 node hàng xóm với nhau, điều này giúp việc ngoài chịu root của nút chủ trong mạng 6LoWPAN mà còn phải biết được hàng xóm của mình "là ai?" - bạn hay thù APKES trải qua 3 pha:

 Pha 1: Optional preloading of short addresses - tùy chọn việc load trước địa chỉ ngắn Như đã đề cập ở trên, việc load trước các thông số bảo mật là cần thiết, đặc biệt là IDs để tạo ra các số ngẫu nhiên khi xác thực Với việc có 3 loại địa chỉ trong mạng là PAN-ID (PAN) và Short Address (SA) và Extended Address (EA) Ở APKES sẽ sử dụng 3 dạng địa chỉ trên để preload Tùy vào các scheme mà chọn 1 trong 3 dạng địa chỉ trên (Hình 3.3)

 Pha 2: Preloading of cryptographic material - load trước các khóa key Trước khi tham gia vào việc hình thành pairwise key thì bắt buộc mỗi nút u, v phải tạo ra được các số ngẫu nhiên mà cần ở đây là seed Si Do đó vào preload thông số này, Ví dụ Si ở đây là master key Km

AdaptiveSEC - Adaptive Key Establishment Scheme (AKES)

Để khắc phục những hạn chế mà APKES vẫn còn tồn đọng đó là chưa xử lý tình trạng nút bị Reboot hay Mobility (di chuyển) thì AKES với những đặc điểm sau giúp giải quyết vụ này: - AKES sẽ ping các hàng xóm nào mà không thấy liên lạc sau 1 khoảng thời gian để check xem nó có còn trong tầm thu phát của mình hay không Nếu không thấy trả lời thì AKES sẽ xóa người hàng xóm này - AKES xử lý trường hợp HELLO từ những hàng xóm hiện tại để có thể refresh lại người hàng xóm này Điều này giúp cho AKES khắc phục vấn đề reboot - Ngoài ra, AKES còn sử dụng Trickle để broadcast lại HELLO Nhờ vào việc này mà AKES vừa từ mình giảm thiểu việc phát quá nhiều HELLO khi mà mạng đang ở trạng thái ổn định, vừa nhanh chóng phát hiện ra sự thay đổi xung quanh

Hình 3.6 Tổng quát AKES - Adaptive Key Establishment Scheme Nguồn [5]

AKES dựa trên APKES nên mang các đặc điểm của APKES và EBEAP như chia sẻ khóa bí mật theo các scheme khác nhau, xác thực khung unicast và broadcast, v.v Chi tiết sẽ bao gồm các ý sau:

Load trước các thông số cần thiết: Việc load trước các thông số bảo mật là cần thiết như ID (có thể là PAN-ID, EA, SA) Điều này đảm bảo AKES có thể chia sẻ bí mật cho nhau bởi các ID trên không thay đổi Ngoài ra tùy scheme sử dụng (LEAP, Blom scheme) mà load trước các thông số cần thiết của scheme đó là bắt buộc

Giai đoạn hình thành key AKES: Cũng sử dụng 3 bước bắt tay như APKES tuy nhiên có sự thay đổi trong các khung HELLO, HELLOACK, ACK (những khung này vẫn chỉ xử lý ở Lớp 2) 3 bước bắt tay được thể hiện ở các bước sau đây và chi tiết ở hình 3.8

Giả sử u bắt đầu hình thành pairwise session key với hàng xóm v Ban đầu u sẽ tạo số ngẫu nhiên Ru và broadcast khung HELLO chưa nó Khung HELLO này sẽ được xác thực bằng cách dùng EBEAP hoặc group session key Khi v nhận được gói broadcast HELLO này, v bắt đầu tạo 𝐾 𝑣,𝑢 nhờ vào pluggable scheme mà AKES sử dụng và tạo số ngẫu nhiên 𝑅 𝑣 Từ đó mà tạo được 𝐾′ 𝑣,𝑢 = AES-128(𝐾 𝑣,𝑢 , 𝑅 𝑢 || 𝑅 𝑣 ) Sau đó v sẽ gửi HELLOACK (được xác thực bẳng MIC tạo từ 𝐾′ 𝑣,𝑢 ) Lúc này, u nhận được HELLOACK sẽ check MIC bằng cách tạo ra 𝐾′ 𝑣,𝑢 Nếu đúng, u sẽ gửi ACK cho v Khung ACK cũng phải được xác thực bằng MIC tạo từ 𝐾′ 𝑢,𝑣 Khi v nhận ACK thì v sẽ xác thực nó Cuối cùng thì u và v sẽ có pairwise session key với 𝐾′ 𝑣,𝑢 = 𝐾′ 𝑢,𝑣 Ngay sau đó thì u lại tiếp tục tạo ra số ngẫu nhiên Ru để chuẩn

33 bị cho khung HELLO tiếp theo Trong quá trình bắt tay 3 bước, u và v trao đổi cho nhau group session key là 𝐾 𝑢,∗ và 𝐾 𝑣,∗ trong khung ACK và HELLOACK và được mã hóa bằng 𝐾′ 𝑢,𝑣 và 𝐾′ 𝑣,𝑢 Thêm nữa là 𝐼 𝑢,𝑣 và 𝐼 𝑣,𝑢 do sử dụng EBEAP trong khung HELLOACK và ACK cũng như dùng thêm tùy chọn LB Optimization để giảm kích thước khung tin gửi đi (xem hình 3.7) Nếu không sử dụng LB-optimization thì mỗi nút sẽ buộc thêm các giá trị frame counter cho các khung phát và khung nhận (chi tiết ở bảng 3) Theo như tiến trình bắt tay chi tiết 3 bước ở hình 3.8 thì AKES có phân biệt giữa hàng xóm nhất thời (tạo khi HELLO) và hàng xóm vĩnh viễn (tạo khi HELLOACK hoặc ACK), điểm khác biệt lớn nhất là khung data chỉ được gửi đến và đi từ hàng xóm vĩnh viễn Khác với APKES, AKES giúp node v xử lý được HELLO từ người hàng xóm vĩnh viễn u Ví dụ, nếu u bị reboot, v sẽ nhận được khung không xác thực HELLO từ u Lúc này v vừa cho u làm người hàng xóm nhất thời, vừa giữ dữ liệu của u hàng xóm vĩnh viễn Ngay khi ACK từ u đến, v sẽ xóa đi dữ liệu u hàng xóm vĩnh viễn và chuyển dữ liệu u hàng xóm nhất thời thành vĩnh viễn Như vậy AKES quá hiệu quả để xử lý reboot khi tạo ra phiên làm việc mới giữa u và v Nếu v nhận được tiếp những khung HELLO đã xác thực từ u (sau Trickle u broadcast khung HELLO) thì v lúc này loại bỏ ngay EBEAP broadcast HELLO cũng được AKES giải quyết khi bị reboot Khung EBEAP lần đầu gửi sẽ không có MIC, v sẽ cho khung này chưa xác thực nên sẽ gửi HELLOACK cho u và cờ 𝑃 𝑢 được set để u biết là v đang lưu u là hàng xóm vĩnh viễn Ngay lúc này, u nhận HELLOACK và biết mình đang là hàng xóm của v nên sẽ không tiếp tục thành lập pairwise key nữa u : Tạo 𝑅 𝑢 ∈ {0, 1} 64 ngẫu nhiên u → * : < 𝑯𝑬𝑳𝑳𝑶, 𝑃𝐴𝑁 𝑢 , 𝐼𝐷 𝑢 , 𝑅 𝑢 , 𝐶 𝑢 > v : 𝐾 𝑣,𝑢 = xem Bảng 3.2 v : Tạo 𝑅 𝑣 ∈ {0, 1} 64 ngẫu nhiên v : 𝐾′ 𝑣,𝑢 = AES-128(𝐾 𝑣,𝑢 , 𝑅 𝑢 || 𝑅 𝑣 ) ∈ {0, 1} 128 v → u :

Bảng 3.2: Dữ liệu mà u lưu mỗi nút hàng xóm

Biến Ý nghĩa status Trạng thái v là hàng xóm vĩnh viễn hay nhất thời

Nếu nhất thời thì xem HELLOACK đã gửi hay chưa

𝐼𝐷 𝑣 Địa chỉ duy nhất của v (SA hoặc EA)

𝐸 𝑣 Thời gian tồn tại của nút v

𝐼 𝑢,𝑣 STT của u trong list hàng xóm của v (EBEAP)

𝐶 𝑣 Nếu ko sử dụng LB-optimization, Cv lưu giá trị framer counter của khung cuối cùng được u chấp nhận từ v

𝐶 𝑣,𝑢 LB-optimization - giá trị frame counter của khung unicast cuối cùng được u chấp nhận từ v

𝐶 𝑢,𝑣 LB-optimization - giá trị frame counter của khung phát unicast cuối cùng của u gửi v

𝐶 𝑣,∗ LB-optimization - giá trị frame counter của khung broadcast cuối cùng được u chấp nhận từ v

𝐵 𝑣 LB-optimization - cờ flag lưu có hay không khung cuối cùng được u chấp nhận từ v là broadcast

𝐻 𝑣 Trickle - cờ flag lưu có hay không v gửi khung HELLO (fresh authentic) kể từ khi u broadcast HELLO lần cuối

Hình 3.8 Chi tiết quá trình 3 bước bắt tay AKES để thành lập key Nguồn [5] Để lập lịch phát sóng HELLO, AKES sử dụng thuật toán Trickle Thuật toán này nhận ba tham số: 𝐼𝑚𝑖𝑛: khoảng thời gian tối thiểu

𝐼𝑚𝑎𝑥: khoảng thời gian lớn nhất

𝑘: hằng số dư thừa và duy trì ba biến:

𝐼: khoảng thời gian hiện tại

𝑡: thời gian tức thời trong nửa sau của khoảng thời gian hiện tại

Khi khởi động, Trickle đặt 𝑐 thành 0, 𝐼 thành một khoảng thời gian ngẫu nhiên trong phạm vi [𝐼𝑚𝑖𝑛, 𝐼𝑚𝑎𝑥] và t thành một thời điểm ngẫu nhiên trong phạm vi [ 𝐼

2, 𝐼) Cho đến thời điểm t, Trickle tăng c lên khi nhận được một chương trình phát sóng nhất quán Tại thời điểm t, Trickle phát sóng nếu và chỉ khi 𝑐 < 𝑘 Vào cuối khoảng thời gian hiện tại 𝐼, Trickle bắt đầu một khoảng thời gian mới với 𝑐 = 0, 𝐼 = 𝑚𝑖𝑛{𝐼 × 2, 𝐼𝑚𝑎𝑥}, và một thời điểm ngẫu nhiên 𝑡 ∈ [ 𝐼

2, 𝐼) Một khoảng thời gian mới cũng bắt đầu ngay lập tức nếu thiết lập lại được đưa ra - trừ khi 𝐼 đã ở mức 𝐼𝑚𝑖𝑛 Trong trường hợp đặt lại như vậy, Trickle bắt đầu lại với 𝑐 = 0, 𝐼 = 𝐼𝑚𝑖𝑛, và một thời điểm ngẫu nhiên 𝑡 ∈ [ 𝐼𝑚𝑖𝑛

2 , 𝐼𝑚𝑖𝑛) Nhìn chung, Trickle giảm tốc độ phát sóng theo cấp số nhân trong khi vẫn đạt được tính nhất quán và tăng tốc độ phát sóng khi quan sát thấy sự không nhất quán Năng lượng hơn nữa được tiết kiệm bằng cách ngăn chặn các chương trình phát sóng nếu 𝑐 < 𝑘

AKES điều chỉnh Trickle để phát HELLOs như sau Theo mặc định, AKES đặt 𝐼𝑚𝑖𝑛 𝑚𝑎𝑥 {30𝑠, 2 × 𝑀𝑏𝑎𝑐 + 1𝑠}, 𝐼𝑚𝑎𝑥 = 𝐼𝑚𝑖𝑛 × 2 8 𝑣à 𝑘 = 2 Đặt 𝐼𝑚𝑖𝑛 thành 𝑚𝑎𝑥 {30𝑠, 2 × 𝑀𝑏𝑎𝑐 + 1𝑠} sẽ tránh phát HELLO khác trong khi vẫn chờ cho HELLOACKs Là chương trình phát sóng nhất quán, AKES coi các HELLO xác thực mới, miễn là chúng không bắt nguồn từ một người hàng xóm cố định đã gửi một HELLO xác thực mới kể từ lần cuối cùng người nhận phát một HELLO Hơn nữa, AKES đặt lại Trickle nếu tối đa {[ 𝑛

4], 1} hàng xóm vĩnh viễn được thêm vào trong khoảng thời gian hiện tại, trong đó

𝑛 là số lượng hàng xóm cố định hiện tại Tuy nhiên, khi thiết lập khóa phiên mới với một người hàng xóm lâu dài (ví dụ: xảy ra nếu một người hàng xóm vĩnh viễn khởi động lại), AKES không tính người hàng xóm vĩnh viễn này là mới Để tăng tốc độ tham gia mạng, AKES phát một HELLO khi khởi động, cũng như đặt lại Trickle sau đó Bên cạnh đó, để

38 phát hiện xem một người hàng xóm cố định có nằm ngoài phạm vi hay không, AKES sẽ gửi một khung UPDATE đến những người hàng xóm vĩnh viễn không gửi khung xác thực mới trong một khoảng thời gian quan trọng 𝑇𝑙𝑖𝑓 Nếu một người hàng xóm không có kiến thức như vậy không trả lời bằng UPDATE sau một vài lần truyền lại, AKES sẽ xóa người hàng xóm đó

Mobility - Xử lý trường hợp nút di chuyển Để có thể phát hiện sự thay đổi của nút (nút hàng xóm vĩnh viễn di chuyển) thì nhờ vào AKES mà việc tự xóa các nút hàng xóm vĩnh viễn biến mất khỏi vùng thu phát và "Trickling" HELLO để phát hiện hàng xóm mới trở nên dễ dàng

 Xóa những hàng xóm vĩnh viễn khi không còn trong vùng thu phát: Khi thời gian của hàng xóm vĩnh viễn hết hạn, AKES sẽ check xem nút đó còn còn trong tầm phát hay không bằng cách gửi các khung tin UPDATE như sau: u → v : < 𝑈𝑃𝐷𝐴𝑇𝐸, 𝑃𝐴𝑁 𝑢 , 𝐼𝐷 𝑢 , 𝑃𝐴𝑁 𝑣 , 𝐼𝐷 𝑣 , [𝐶 𝑢 │𝐶 𝑢,𝑣 , 𝐶 𝑢,∗ ] > v → u : < 𝑈𝑃𝐷𝐴𝑇𝐸𝐴𝐶𝐾, 𝑃𝐴𝑁 𝑢 , 𝐼𝐷 𝑢 , 𝑃𝐴𝑁 𝑣 , 𝐼𝐷 𝑣 , [𝐶 𝑣 │𝐶 𝑣,𝑢 , 𝐶 𝑣,∗ ] >

Secure Radio Duty Cycling – ContikiMAC

Practical On-the-fly Rejection of Injected and Replayed 802.15.4 Frames (POTR)

Qua việc tìm hiểu AKES ta thấy rất nhiều ưu điểm của nó như đã đề cập, tuy vậy vẫn còn có kiểu tấn công đó chính là kiểu tấn công nhỏ giọt làm tiêu tốn năng lượng (vấn đề tiết kiệm năng lượng là một trong những đặc điểm lớn của mạng 6LoWPAN) Việc phải xác thực tiêu tốn rất nhiều thời gian vì quá trình mã hóa giải mã, CCM*-MIC mà chính là điểm mà kẻ tấn công khai thác và gây tiêu tốn năng lương xử lý quá trình này Nhờ phát hiện vấn đề đó mà Lớp Adaptive Security đã thêm vào POTR với nhiều tính năng mà có thể ngay lập tức loại bỏ những khung tin tấn công kiểu nhỏ giọt này với ý tưởng chính là dùng OTP (số chỉ sử dụng 1 lần)

Adaptation of the 802.15.4 Frame Format: So với cấu trúc khung 802.15.4 thông thường, việc áp dụng POTR sẽ thay đổi 6 thứ trong đó (hình 3.9)

Hình 3.9 Cấu trúc khung tin 802.15.4 có thêm POTR Nguồn [6] Đầu tiên, POTR sẽ thay trường Frame Control bằng Frame Type (chi tiết hình 3.10) Tùy vào giá trị Frame Type mà ý nghĩa của chúng khác nhau

Hình 3.10 Chi tiết ý nghĩa của trường Frame Type Nguồn [6]

Thứ hai, POTR xem thỏa thuận network-wide về việc sử dụng các địa chỉ đơn giản, địa chỉ ngắn hoặc địa chỉ mở rộng Thứ ba, POTR di chuyển trường Source Address lên đầu khung Thứ tư, POTR giảm kích thước trường Auxiliary Security Header (không cần thiết) để nhường cho trường Frame Counter Thứ năm, POTR thêm l-bit trường OTP để nhúng giá trị OTP vào khung 802.15.4 Hiện giờ, trường OTP thay thế cho trường Destination Address bởi vì POTR OTP đã mã hóa người được nhận tin trong đó Thứ sáu, POTR làm cho PAN-

ID trở nên dư thừa do POTR có khả năng loại bỏ các khung không mong muốn rất nhanh kể cả các khung có củng PAN-ID với nút Như vậy việc thay đổi cấu trúc khung tin 802.15.4 bằng cách thêm POTR OTP mạng lại rất nhiều lợi ích mà không ảnh hưởng đến việc làm tràn khung nhờ vào việc giảm bớt trường Frame Control, Destination PAN, Source PAN và Destination Address field

Integration with 802.15.4 Security - tích hợp cùng với Lớp bảo mật: Ngoài việc tránh overhead thì POTR còn làm tránh tràn bộ nhớ RAM vì có kết hợp thêm bảo mật 802.15.4 nhờ vào việc sử dụng lại khóa thành lập với các nút mạng (AKES) POTR còn có khả năng đảm nhiệm luôn chức năng của AKES khi có thể check xem khung có freshness hay không (khung mới) chống tấn công phát lại

On-the-fly Rejection of Unwanted 802.15.4 Frames - Loại bỏ các khung không mong muốn: POTR có khả năng từ chối gần như lập tức các khung đang đến (incoming frame) bằng cách vô hiệu hóa chế độ nhận tin RF - Unicast Data Frames: Dựa trên việc nhận các khung tin unicast data frame, POTR sẽ đảm bảo trước hết là người gửi là đang là hàng xóm vĩnh viễn thông qua việc tra trường Source Address Nếu đúng là hàng xóm vĩnh viễn đang gủi mình, POTR sẽ tạo OTP tương ứng và check xem có trùng với mã có ở trong khung hay không OTP của unicast data frame được tạo bằng cách: 𝐾𝐷𝐹(𝐾 𝑠𝑟𝑐,∗ ⊕ 𝐾 𝑛 , 𝐼𝐷 𝑑𝑠𝑡 ||𝐶) ∈ {0,1} 𝑙 Trong đó 𝐾𝐷𝐹 là hàm key derivation function, ⊕ là XOR, 𝐾 𝑠𝑟𝑐,∗ là group session key của người gửi, 𝐾 𝑛 là khóa chung toàn mạng, 𝐼𝐷 𝑑𝑠𝑡 là địa chỉ người gửi, || là phép OR, và 𝐶 frame counter của unicast (có hoặc không sử dụng LB-optimization) Cuối cùng POTR mới check tới 𝐶 để chống việc phát lại

 Broadcast Data Frames: Tương tự như unicast data frame, POTR cũng tiến hành các công việc trên, chỉ khác là 𝐼𝐷 𝑑𝑠𝑡 là địa chỉ 0xff ff và 𝐶 là frame counter của broadcast (có hoặc không sử dụng LB-optimization)

 Acknowledgement: Đây là khung mà POTR hạn chế hỗ trợ, POTR chỉ đơn giản là đảm bảo độ dài của FrameLength là 4 Điều này được khắc phục ở phần sau khi đảm bảo khung Acknowledgement an toàn hơn

 HELLOs: Mã OTP của khung HELLO được tạo ra như cách tạo của khung broadcast bên trên Tuy nhiên, POTR sẽ chỉ từ chối những OTP lặp lại (tấn công phát lại) POTR sẽ check 4 thứ sau đây: một là đảm bảo số chiều dài khung tới là đúng, hai là POTR đảm bảo là vẫn còn chỗ trống để chứa thông tin người hàng xóm, ba là POTR từ chối những khung HELLO từ hàng xóm nhất thời, và bốn là POTR từ chối HELLO nếu đã chứa đủ hàng xóm gần nhất (như AKES)

 HELLOACKs: Khi mà chưa hình thành khóa xong, OTP của khung HELLOACK được tạo ra bằng cách: 𝐾𝐷𝐹(⊕ 𝐾 𝑛 , 𝐼𝐷 𝑠𝑟𝑐 ||𝑅 𝑑𝑠𝑡 ) Trong đó thì 𝐾𝐷𝐹, ⊕ 𝐾 𝑛 , 𝐼𝐷 𝑠𝑟𝑐 đã biết thì 𝑅 𝑑𝑠𝑡 là 64bit ngẫu nhiên mà AKES thêm vào khung HELLO (hình 3.11) Để chống việc phát lại OTP thì sẽ có bộ nhớ cache lưu tất cả OTP đã nhận và POTR khi nhận HELLOACK sẽ trích OTP trong khung tin đó ra so sánh với toàn bộ OTP trong cache, nếu giống cũ sẽ từ chối ngay lập tức Nếu cache OTP đầy thì POTR sẽ từ chối toàn bộ HELLOACK nhận được cho tới khi nào nút bắt đầu lại quá trình broadcast gói HELLO tiếp theo

 ACKs: Mã OTP của ACK được tạo theo cách tương tự HELLOACK tạo nhưng lần này sử dụng 64bit ngẫu nhiênmà AKES nhúng trong gói tin HELLOACK (hình 3.11) Để chống việc phát lại ACK - OTP, POTR từ chối những ACK không phải là

42 hàng xóm nhất thời Hơn nữa, nếu POTR chấp nhận ACK trong khi AKES loại bỏ nó, AKES cũng sẽ xóa người hàng xóm nhất thời gửi ACK đó giống như việc từ chối gói tin ACK - Unicast and Broadcast Command Frames: Cuối cùng là những gói tin COMMAND, với những loại này cũng giống như unicast data frame và broadcast data frame, POTR thực thi các bước như trên Tuy vậy POTR cũng sẽ cho "bypass" các cuộc tấn công sau: Local Replay Attack (được giải quyết bởi CCM*-MIC ở lớp bảo mật), hidden wormholes (không ảnh hưởng nhiều đến năng lượng và được được loại bỏ bởi lớp Network nhờ vào RPL), guessing attacks (khá hiếm khi việc đoán OTP với xác xuất thành công là 2 −l (thường l được chọn là 24 để loại trừ kiểu tấn công này), Node Compromises (sẽ được nghiên cứu trong thời gian tới).

Các phương thức tấn công vào mạng 6LoWPAN

HELLO Flood Attacks: Trong một cuộc tấn công tràn HELLO, một mặt, kẻ tấn công bên ngoài, tức là kẻ tấn công không có quyền truy cập vào bất kỳ khóa mật mã nào, đưa vào HELLO công suất truyền cao, do đó khiến mỗi node nhận lưu trữ một hàng xóm tạm thời với địa chỉ được giả mạo là địa chỉ nguồn của HELLO Nghiêm trọng hơn, người nhận cũng sẽ gửi HELLOACK sau một khoảng thời gian sau đó Điều này tiêu tốn một lượng lớn năng lượng, đặc biệt nếu kẻ tấn công bên ngoài không nhận các HELLOACK thì các nút nạn nhân sau đó sẽ truyền lại các HELLOACK nhiều lần Hơn nữa, với tư cách là kẻ tấn công nội bộ, tức là kẻ tấn công có quyền truy cập vào một hoặc nhiều khóa mật mã, một phương pháp để làm trầm trọng thêm các cuộc tấn công tràn HELLO chống lại AKES là trả lời HELLOACK bằng ACK hợp lệ Thông thường, nếu một node nạn nhân đã đạt đến số lượng hàng xóm tạm thời tối đa, thì AKES sẽ không còn phản hồi HELLO cho đến khi một trong số các hàng xóm tạm thời hết hạn Tuy nhiên, khi nhận được ACK hợp lệ, AKES biến một người hàng xóm dự kiến thành một hàng xóm vĩnh viễn, cho phép những kẻ tấn công nội bộ khởi động các cuộc tấn công tràn HELLO với tốc độ cao hơn

YO-YO Attacks: Trong một cuộc tấn công yo-yo, kẻ tấn công làm cho các liên kết tạm thời có sẵn hoặc tạm thời không khả dụng để kích động thêm nỗ lực thiết lập khóa phiên, thiết lập lại khóa phiên hoặc cả hai Là một kẻ tấn công bên ngoài, dường như có hai cách để thực hiện một cuộc tấn công yo-yo Đầu tiên, kẻ tấn công bên ngoài có thể làm nhiễu một số frame nhất định để gây ra lỗi bit và do đó ngăn cản việc nhận thành công của chúng, hay

43 còn gọi là gây nhiễu phản ứng Ví dụ: nếu kẻ tấn công làm kẹt tất cả các frame ngoại trừ HELLO, HELLOACK và ACK, AKES sẽ xóa các hàng xóm vĩnh viễn và sau đó thiết lập lại các khóa phiên Do đó, các node nạn nhân gửi thêm HELLOACK và ACK Hơn nữa, các nút nạn nhân có khả năng đặt lại Trickle do thêm hàng xóm vĩnh viễn Do đó, cuộc tấn công yo-yo ví dụ này cũng có thể kéo theo nhiều lần truyền HELLO hơn Một cuộc tấn công yo- yo dựa trên gây nhiễu phản ứng khác là ngăn chặn một node nạn nhân nhận HELLO từ các hàng xóm vĩnh viễn, vô hiệu hóa hiệu quả việc đàn áp HELLO của AKES Một cuộc tấn công yo-yo dựa trên gây nhiễu phản ứng cuối cùng là ngăn chặn các node vừa đặt lại Trickle nhận HELLO để trì hoãn việc thiết lập khóa phiên và có khả năng gây ra thêm các lần đặt lại Trickle Thứ hai, kẻ tấn công bên ngoài cũng có thể tạm thời mở một lỗ sâu ẩn để lừa các node ở xa tin rằng chúng là hàng xóm của nhau, do đó khiến AKES thiết lập các khóa phiên giữa chúng và có khả năng đặt lại Trickle Hơn nữa, kẻ tấn công nội bộ có quyền truy cập vào một hoặc nhiều khóa được phân phối trước có thể trở thành hàng xóm vĩnh viễn của bất kỳ node nào bằng cách tiêm ACK và HELLOACK hợp lệ Điều này kích thích truyền HELLOACK và ACK bổ sung, đồng thời có khả năng đặt lại Trickle Các cuộc tấn công yo- yo của kẻ tấn công nội bộ trở nên trầm trọng hơn khi kẻ tấn công nội bộ không trả lời UPDATE hoặc các khung khác sau khi gửi HELLOACK hoặc ACK hợp lệ của nó Điều này là do AKES sẽ xóa hàng xóm vĩnh viễn dường như không hoạt động, do đó cho phép kẻ tấn công nội bộ trở thành hàng xóm vĩnh viễn sau đó một lần nữa

Countering Denial-of-Sleep Attacks on ContikiMAC - chống lại các cuộc tấn công chống ngủ ở ContikiMAC

Phòng thủ chống lại các cuộc tấn công tràn HELLO: Khả năng phòng thủ của AKES trước các cuộc tấn công của tràn HELLO tăng gấp đôi Một mặt, AKES phân phối với cả KDC (key distribution center) và PKC (public-key cryptography) Do đó, không giống như khi sử dụng KDC, các yêu cầu thiết lập khóa phiên không được chuyển đến KDC, điều này sẽ làm trầm trọng thêm các cuộc tấn công tràn HELLO Tương tự như vậy, việc sử dụng PKC sẽ làm trầm trọng thêm các cuộc tấn công tràn HELLO vì PKC liên quan đến tính toán nhiều hơn so với mật mã khóa đối xứng Mặt khác, AKES loại bỏ HELLO trong ba trường hợp, cụ thể là:

(i) nếu số lượng hàng xóm dự kiến hiện tại đạt đến giới hạn Mten,

(ii) nếu người gửi HELLO đã được lưu trữ như một người hàng xóm dự kiến , và

(iii) nếu không còn bộ nhớ truy cập ngẫu nhiên (RAM) để lưu trữ các vùng lân cận cố định bổ sung khả dụng

Trong phần tiếp theo, mà chúng ta sẽ đề cập về cách AKES giảm hơn nữa mức tiêu thụ năng lượng của AKES khi bị tràn HELLO tấn công bằng cách giảm lượng HELLO đã có trong quá trình tiếp nhận

Phòng thủ chống lại các cuộc tấn công Yo-Yo: Hơn nữa, biện pháp phòng thủ của AKES chống lại các cuộc tấn công yo-yo là không xóa các hàng xóm vĩnh viễn không có liên quan ngay lập tức, mà chỉ xóa sau một 𝑇𝑙𝑖𝑓 trễ Điều này giới hạn tốc độ AKES đọc cùng một người hàng xóm cố định và do đó giới hạn tốc độ các cuộc tấn công yo-yo lặp lại.

Đánh giá phương thức phòng thủ từ chối giấc ngủ của AKES

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG TRÀN HELLO

Nhớ lại các thông số sau của AKES:

𝑀𝑡𝑒𝑛: số lượng hàng xóm dự kiến tối đa

𝑀𝑏𝑎𝑐: khoảng thời gian chờ tối đa của HELLOACK

𝑇𝑎𝑐𝑘: khoảng thời gian chờ đợi tối đa cho ACK

Do đó, bằng cách thêm các HELLO với địa chỉ nguồn ngẫu nhiên, những kẻ tấn công bên ngoài có thể khiến AKES gửi HELLOACK với tốc độ trung bình là

(1) không tính các lần truyền lại riêng lẻ Thật không may, tốc độ này không thể được điều chỉnh mà không ảnh hưởng đến tốc độ AKES phản ứng với các thay đổi cấu trúc liên kết cùng một lúc Cụ thể, việc hạ 𝑀𝑡𝑒𝑛 làm giảm số lượng hàng xóm mà AKES có thể thêm song song

Mặt khác, việc tăng 𝑀𝑏𝑎𝑐 lại làm trì hoãn việc thiết lập khóa phiên Cuối cùng, việc tăng 𝑇𝑎𝑐𝑘 kéo theo vấn đề sau Hãy xem xét rằng một nút A đã phát một HELLO và việc thiết lập khóa phiên đó với một nút lân cận B đã không hoàn thành do lỗi HELLOACK hoặc ACK bị bỏ lỡ Bây giờ, nếu A gửi một HELLO khác trước khi B có thể xóa A khỏi danh sách những người hàng xóm tạm thời, B sẽ bỏ qua HELLO của A Hơn nữa, những kẻ tấn công nội bộ có thể khiến một nút nạn nhân gửi HELLOACK với tốc độ cao hơn trong phương trình (1) Điều này là do, một khi kẻ tấn công nội bộ lấy được khóa đối xứng được phân phối trước giữa nút nạn nhân và một nút khác, anh ta có thể (i) thiết lập các khóa phiên với nút nạn nhân và (ii) thiết lập lại các khóa phiên với nút nạn nhân nhiều lần, với chỉ trì hoãn là 𝑇𝑏𝑎𝑐 < 𝑀𝑏𝑎𝑐 Cụ thể, nếu kẻ tấn công nội bộ kiểm soát 𝑘 trong số 𝑛 ≥ 𝑘 hàng xóm vĩnh viễn của nút nạn nhân, kẻ tấn công nội bộ có thể buộc nút nạn nhân gửi HELLOACK với tốc độ trung bình là

(2) không tính các lần truyền lại riêng lẻ Vì vậy, để chống lại những kẻ tấn công bên trong, 𝑀𝑏𝑎𝑐 phải được chọn lâu dài

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG YO-YO Đối với khả năng phòng thủ của AKES trước các cuộc tấn công yo-yo, một cuộc xung đột tương tự cũng nảy sinh Trong khi mở rộng 𝑇𝑙𝑖𝑓 làm tăng khả năng phục hồi của AKES đối với các cuộc tấn công yo-yo, nó cũng ngăn chặn việc xóa các hàng xóm vĩnh viễn không cộng tác và do đó giải phóng RAM được phân bổ Hơn nữa, nếu nhiều RAM được phân bổ để lưu trữ những người hàng xóm vĩnh viễn không thông dụng, điều này có thể tước đi việc AKES thiết lập các khóa phiên với những người hàng xóm thực tế Tuy nhiên, 𝑇𝑙𝑖𝑓 phải được chọn lâu dài Điều này là do kẻ tấn công bên ngoài có thể thiết lập nhiều lỗ sâu ẩn hoặc khởi động các cuộc tấn công va chạm vào một số liên kết Trên thực tế, các nút nạn nhân sẽ không phải lúc nào cũng đọc lại cùng một hàng xóm vĩnh viễn trong một cuộc tấn công yo- yo, nhưng các nút lân cận vĩnh viễn khác nhau lặp đi lặp lại Trong những trường hợp như vậy, AKES vẫn sẽ đưa ra nhiều lần đặt lại Trickle, trừ khi 𝑇𝑙𝑖𝑓 được chọn rất lâu để AKES kiêng đọc bất kỳ người nào trong toàn bộ nhóm hàng xóm vĩnh viễn trong thời gian dài hoặc nhanh chóng kiêng thêm các hàng xóm vĩnh viễn khác vì hết RAM

Cả hai biện pháp phòng thủ từ chối giấc ngủ đều dựa trên bộ đếm leaky bucket (LBC) Mô tả LBC là một cái xô có một lỗ trên đó, như thể hiện trong Hình 3.12

Hình 3.12 Leaky Bucket Counter (LBC) Nguồn [7]

Các sự kiện rơi vào “xô” và làm đầy nó Có thể liên kết các sự kiện khác nhau với các kích thước thả khác nhau Khi xô có một lỗ, mức độ lấp đầy của nó giảm đi Áp suất được bỏ qua để mức độ đầy của xô giảm với tốc độ không đổi 𝜌 Chúng ta muốn tránh việc xô bị tràn bằng cách thực hiện các hành động thích hợp trước, tức là trước khi mức đổ đầy vượt quá dung tích 𝛽 của xô

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG TRÀN HELLO

Cụ thể, để phòng thủ trước các cuộc tấn công của tràn HELLO, mỗi nút nên duy trì một LBC 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 được xác định như sau:

Dung lượng: Dung lượng 𝛽 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 của nó tương ứng với số lượng HELLOACK tối đa mà AKES có thể gửi trong thời gian ngắn, không tính các lần truyền lại riêng lẻ

Tốc độ rò rỉ: Tốc độ rò rỉ 𝜌 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 của nó tương ứng với tốc độ tối đa mà AKES có thể gửi HELLOACK trong thời gian dài, không tính các lần truyền lại riêng lẻ

Kích thước giảm: Trong trường hợp HELLOACK được lên lịch gửi, 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 sẽ tăng lên một Tuy nhiên, khi truyền lại một HELLOACK, 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 không tăng lên

Ngăn chặn tràn: AKES sẽ phát ra một HELLO đến nếu 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 có thể tràn theo cách khác

Lợi ích trước mắt của hệ thống phòng chống tràn HELLO dựa trên LBC là các thông số của nó độc lập với các thông số khác của AKES Trên thực tế, Mbac bây giờ có thể được rút ngắn - nhưng không nên được làm bằng 0 để tránh những người gửi HELLO nhiều hơn với

HELLOACK, cũng như va chạm giữa các HELLOACK [37] Tương tự như vậy, Tack hiện có thể được thu nhỏ theo khoảng thời gian chờ tối đa giữa việc truyền HELLOACK và nhận ACK tương ứng Cuối cùng, Mten giờ đây có thể được định cấu hình độc lập với tốc độ tối đa nhắm đến của các HELLOACK gửi đi Ví dụ: hãy xem xét đến tốc độ trung bình là 1

150 Hz của các HELLOACK gửi đi trong các cuộc tấn công tràn HELLO liên tục của những kẻ tấn công bên ngoài, không tính các lần truyền lại riêng lẻ Theo Công thức (1), cấu hình thích hợp của khả năng phòng thủ LLSEC trước các cuộc tấn công của tràn HELLO là Mten = 5, Mbac = 5s và Tack = 747,5 giây Tuy nhiên, để cũng có thể chống lại các cuộc tấn công của tràn HELLO bởi ít nhất một người hàng xóm thường trực do kẻ tấn công kiểm soát, việc chọn Mten = 5, Mbac = 300s và Tack = 600s là cần thiết theo Công thức (2) Trong cả hai trường hợp, Tack khá dài, có thể dẫn đến sự chậm trễ trong việc thiết lập khóa phiên nếu xảy ra mất khung, như được mô tả trong Phần 3.1 Hơn nữa, việc nâng cao Mbac làm chậm HELLOACKs và do đó thiết lập khóa phiên Ngược lại, khi sử dụng biện pháp phòng thủ với LBC trước các cuộc tấn công của tràn HELLO, một bộ tham số cung cấp mức độ bảo mật tương đương là Mbac = 5s, Tack = 5s, βHELLOACK = 20 và ρHELLOACK = 1

Rõ ràng, AKES phản ứng nhanh hơn nhiều với các thay đổi cấu trúc liên kết với các tham số này Ngoài ra, hệ thống phòng thủ của ADAPTIVESEC chống lại các cuộc tấn công của tràn HELLO bảo vệ chống lại bất kỳ số lượng các nước láng giềng thường trực do kẻ tấn công kiểm soát Bảng 1 liệt kê các bộ thông số này với các ID để tham chiếu trong tương lai

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG YO-YO

Tương tự, để phòng thủ trước các cuộc tấn công yo-yo, mỗi nút sẽ duy trì hai LBC bổ sung 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 và 𝐿𝐵𝐶 𝐴𝐶𝐾 được xác định như sau:

Dung lượng: Dung lượng βHELLO của 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 tương ứng với số lượng HELLO tối đa mà AKES có thể phát sóng trong thời gian ngắn

Tốc độ rò rỉ: Tốc độ rò rỉ ρHELLO của 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 tương ứng với tốc độ tối đa mà AKES có thể phát sóng HELLO trong thời gian dài

Giảm kích thước: Trong trường hợp AKES phát HELLO, 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 sẽ tăng lên một Tuy nhiên, khi truyền lại một HELLO, 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 không được tăng lên Ngăn chặn tràn: AKES ngăn chặn HELLO nếu 𝐿𝐵𝐶 𝐻𝐸𝐿𝐿𝑂 sẽ tràn nếu ngược lại Dung lượng: Dung lượng βACK

48 của 𝐿𝐵𝐶 𝐴𝐶𝐾 tương ứng với số lượng ACK tối đa mà AKES có thể gửi trong thời gian ngắn, không tính số lần truyền lại riêng lẻ Tốc độ rò rỉ: Tốc độ rò rỉ ρACK của 𝐿𝐵𝐶 𝐴𝐶𝐾 tương ứng với tốc độ tối đa mà AKES có thể gửi ACK trong thời gian dài, không tính các lần truyền lại riêng lẻ Giảm kích thước: Trong trường hợp AKES gửi ACK, 𝐿𝐵𝐶 𝐴𝐶𝐾 sẽ tăng lên một Tuy nhiên, khi truyền lại ACK, 𝐿𝐵𝐶 𝐴𝐶𝐾 không tăng lên Ngăn chặn tràn: AKES sẽ phát ra một HELLOACK đến nếu 𝐿𝐵𝐶 𝐴𝐶𝐾 có thể tràn theo cách khác Tương tự như vậy, lợi ích tức thì của hệ thống phòng thủ dựa trên LBC chống lại các cuộc tấn công yo-yo là 𝑇𝑙𝑖𝑓 hiện có thể được giảm thiểu Ngược lại, khi sử dụng biện pháp bảo vệ LLSEC chống lại các cuộc tấn công yo-yo, 𝑇𝑙𝑖𝑓 phải được chọn lâu dài để giảm thiểu các cuộc tấn công yo-yo Để chống các cuộc tấn công nêu trên, Secure RDC có 2 phương pháp là "The Dozing Optimization" và "The Secure Phase-lock Optimization"

The Dozing Optimization: Tổng quát thì phương pháp này sẽ cho phép nút ngủ ở khoảng thời gian giữa lúc CCA âm và lúc phát hiện khung tin Bằng cách này mà trừ khử kiểu tấn công ding-dong ditching Ngoài ra, phương pháp này còn giúp tiết kiệm năng lượng bằng việc thức giấc hợp lý Trong hình 2.23 thể hiện các thông số thời gian trong giao thức ContikiMAC:

𝑡 𝑙 là thời gian tối đã để gửi khung tin 802.15.4 với MTU = 127 bytes

𝑡 𝑟 là khoảng thời gian lên của một CCA

𝑡 𝑐 là khoảng thời gian có thể cấu hình được giữa 2 lần CCA liên tiếp

KẾT QUẢ MÔ PHỎNG VÀ THỰC NGHIỆM

THỰC HIỆN TRIỂN KHAI BẢO MẬT TRÊN LỚP APPLICATION

Ban đầu, em sẽ triển khai lớp bảo mật đầu tiên trên lớp application, sử dụng mô hình sau đây để mô phỏng, kiểm nghiệm kết quả: 3 node (1 gateway trung tâm và 2 node user)

Kịch bản ban đầu là chạy mô phỏng quá trình xác thực các nút khi kết nối, đầu tiên key được xác định trước sẽ được sử dụng, phục vụ cho quá trình mã hóa/giải mã các gói tin, sau đó khi 2 bên đã được xác thực, sẽ được cấp phát key bất kỳ, và sẽ sử dụng nó từ đó về sau, để trao dổi gói tin Sau khi đã trao đổi khóa thành công giữa node và gateway, sẽ đo kiểm thêm quá trình trao đổi gói tin, thời gian delay, tỷ lệ mất gói,…

Hình 4.1 Mô hình chạy thử nghiệm triển khai bảo mật trên lớp application

Key ban đầu được xác định trước là key_begin[12] = "thitgahaplachanh" dùng để yêu cầu challenge code, cũng như nhận lại challenge code được gửi từ gateway trung tâm Phương thức mã hóa/giải mã được sử dụng ở đây là AES128_CBC

Hình 4.2 Mô phỏng thiết lập key

Ban đầu gateway gửi yêu cầu challenge code tới 2 node user, với key “0x49 0x3C … 0x6E 0x67”, dữ liệu gửi đi từ gw đã được mã hóa “E9 A6 … C2 97”

Sau khi node nhận được gói tin, node sẽ tiến hành giải mã, kiểm tra CRC, nếu hợp lệ, node sẽ trả challenge code về lại cho gw:

Hình 4.3 Node nhận được challenge code

Key được sử dụng vẫn là key xác định từ trước, data trước khi được mã hóa là “7F 00 … “, và sau đó được mã hóa thành “07 D2 …”

Gateway nhận được data, tiến hành giải mã, kiểm tra CRC, nếu hợp lệ, tiếp tục kiểm tra challenge code, nếu khớp, gw sẽ tiến hành gửi key cho các node

Hình 4.4 Kiểm tra CRC hợp lệ, và tiến hành gửi key

Ví dụ ở node user 2, sau khi giải mã, kiểm tra CRC, kiểm tra challenge code thành công, node đã có key “97 55 … 82 75” được sử dụng từ nay về sau để trao đổi dữ liệu với gateway

Hình 4.5 Node nhận key thành công

Tương tự đối với node user 3, key được cấp phát lúc này là “99 ED … B4 CF”

Sau đó, em thực hiện một lượt chạy mô phỏng trao đổi gói tin giữa gateway và node user (100 lệnh bật tắt led)

Kết quả node user nhận đủ 100% gói tin với tốc độ trung bình delay 1 gói tin là: 1553ms

Hình 4.6 Mô phỏng trao đổi gói tin giữa node và gateway

Chạy thử nghiệm trên các mức độ bảo mật khác nhau (Security level), ở đây em chỉ chạy với level 5,6,7 để đảm bảo có cơ chế encryption gói tin:

Khoảng thời gian delay trung bình mỗi gói tin là 1698 ms

Khoảng thời gian delay trung bình mỗi gói tin là 1643 ms

Khoảng thời gian delay trung bình mỗi gói tin là 1534 ms

- Quá trình bắt tay, trao đổi khóa giữa các node và gateway đã thực hiện thành công, các gói tin đã sử dụng key được cấp phát mới để mã hóa/giải mã gói tin chính xác Sau khi được cấp phát key, quá trình trao đổi gói tin được diễn ra bình thường, với việc dùng gateway gửi kiểm tra 100 gói tin thì phía node đều nhận đủ

- Với security level cao hơn (Độ dài MIC lớn hơn) yêu cầu thời gian xử lý gói tin, truyền nhận gói tin lâu hơn, nhưng chênh lệch không đáng kể.

THỰC HIỆN TRIỂN KHAI BẢO MẬT TRÊN LỚP LINK

MÔ PHỎNG “PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG TRÀN HELLO”

Sau khi đã triển khai bảo mật trên lớp application, em sẽ tiếp tục triển khai bảo mật trên lớp link với 2 cơ chế là LLSEC và ADAPTIVESEC, lần này là chạy mô phỏng khả năng phòng

59 thủ trước sự tấn công tràn HELLO, một đòn tấn công gây ảnh hưởng trực tiếp tới sự tiêu thụ năng lượng quá mức của các node Đầu tiên chúng ta sẽ chia thành 2 kịch bản nhỏ hơn, đó là: cuộc tấn công từ bên ngoài mạng và cuộc tấn công từ bên trong mạng

 EXTERNAL ATTACKERS (TẤN CÔNG TỪ BÊN NGOÀI) Để so sánh khả năng phục hồi của LLSEC và ADAPTIVESEC, thí nghiệm sau đã được tiến hành Một mô phỏng Cooja với hai nút đã được chạy trong 3 giờ Nút đầu tiên hoạt động như một kẻ tấn công bên ngoài liên tục đưa vào các HELLO địa chỉ nguồn ngẫu nhiên với tốc độ 1Hz Nút thứ hai đóng vai trò là nạn nhân với Bộ thông số 1 được hiển thị trong bảng dưới đây

Bảng 4.1: Các thông số chạy mô phỏng

Sau đó, mô phỏng này được chạy lại bằng cách sử dụng (i) cơ chế LLSEC với Bộ thông số

2 và (ii) cơ chế ADAPTIVESEC với Bộ thông số 3 Trong mỗi lần chạy, nút nạn nhân ghi lại số lượng HELLOACK đã gửi của nó

Kết luận: Hình 4.10 cho thấy kết quả ADAPTIVESEC dần dần trả lời các câu HELLOs vì thùng bị rò rỉ với tốc độ 𝜌 𝐻𝐸𝐿𝐿𝑂𝐴𝐶𝐾 = 1

150𝐻𝑧 Biện pháp LLSEC trả lời thêm HELLOs theo

60 từng đợt vì tất cả các hàng xóm nhất thời được lưu trữ ban đầu đều hết hạn sau nhau Như đã phỏng đoán, cả hai hệ thống phòng thủ đều hạn chế tốc độ của các HELLOACK gửi đi xuống 1

Hình 4.10 Số lượng HELLOACK gửi từ node khi bị tấn công HELLO flood từ bên ngoài

 INTERNAL ATTACKERS (TẤN CÔNG TỪ BÊN TRONG)

Tiếp theo, để so sánh khả năng phục hồi với một người hàng xóm vĩnh viễn do kẻ tấn công kiểm soát trong hệ thống phòng thủ LLSEC trước các cuộc tấn công của tràn HELLO, thử nghiệm sau đã được tiến hành Một lần nữa, một mô phỏng Cooja đã được chạy trong ba giờ, trong đó một nút hoạt động như một nút do kẻ tấn công kiểm soát và một nút khác đóng vai trò là nạn nhân Trong lần chạy đầu tiên, nút nạn nhân sử dụng biện pháp LLSEC chống lại các cuộc tấn công tràn HELLO với Bộ thông số 1 Trong lần chạy thứ hai, nút nạn nhân đã sử dụng biện pháp bảo vệ LLSEC chống lại các cuộc tấn công tràn HELLO với Bộ thông số 2 Trong lần chạy thứ ba, nút nạn nhân đã sử dụng biện pháp bảo vệ ADAPTIVESEC chống lại các cuộc tấn công tràn HELLO với Bộ thông số 3 Trong tất cả các lần chạy, nút nạn nhân ghi lại số lượng HELLOACK đã gửi của nó Lúc đầu, nút do kẻ tấn công kiểm soát đã thiết lập các khóa phiên với nút nạn nhân Sau đó, nút do kẻ tấn công kiểm soát đã phát các HELLO không xác thực ở tốc độ 1Hz Trong trường hợp nút nạn nhân trả lời bằng HELLOACK, nút do kẻ tấn công kiểm soát đã hoàn thành quá trình bắt tay ba chiều bằng

61 cách gửi một ACK xác thực để phản hồi Như thể hiện trong Hình 4.11, kết quả khác với thử nghiệm trước đó về khả năng bảo vệ LLSEC chống lại các cuộc tấn công của tràn HELLO

Hình 4.11 Số lượng HELLOACK gửi từ node khi bị tấn công HELLO flood từ bên trong

Kết luận: khi sử dụng Bộ thông số 1, nút nạn nhân kết thúc với gần 3000 HELLOACK được gửi sau 1 giờ Kết quả thảm hại này phát sinh do nút bị kẻ tấn công kiểm soát thiết lập lại các khóa phiên với nút nạn nhân nhiều lần với một khoảng thời gian ngắn Chỉ khi điều chỉnh 𝑀𝑏𝑎𝑐 một cách thích hợp, khả năng phòng thủ LLSEC chống lại các cuộc tấn công của tràn HELLO mới đạt đến tốc độ tối đa mục tiêu của một HELLOACK phát ra trong mỗi 150 giây Tuy nhiên, nếu có nhiều hơn một hàng xóm vĩnh viễn do kẻ tấn công kiểm soát xuất hiện, 𝑀𝑏𝑎𝑐 phải được mở rộng thêm Mặt khác, hệ thống phòng thủ ADAPTIVESEC chống lại các cuộc tấn công tràn HELLO với bất kỳ số lượng người hàng xóm vĩnh viễn bị kẻ tấn công kiểm soát, ngay cả khi không có thay đổi cấu hình

MÔ PHỎNG TIÊU TÁN NĂNG LƯỢNG KHI BỊ TẤN CÔNG TRÀN HELLO

Mô phỏng được thực hiện trong 60p, mỗi 10 phút ghi nhận các thông số CPU, LPM, TX,

RX, từ đó tính toán ra năng lượng tiêu thụ của node khi bị tấn công tràn HELLO Mô phỏng được thực hiện 3 lần, với lần đầu sử dụng LLSEC, lần thứ 2 sử dụng ADAPTIVESEC, và lần thứ 3 không sử dụng phương pháp nào

Bảng 4.2: Các kết quả thu được khi mô phỏng tiêu tán năng lượng

CPU LPM TX RX Total

CPU LPM TX RX Total

Không áp dụng phương pháp nào:

CPU LPM TX RX Total

Hình 4.12 Mức độ tiêu thụ năng lượng tương ứng với các biện pháp

Kết luận: Các phương pháp bảo mật tỏ ra vượt trội trong việc hạn chế tiêu tán năng lượng cho các node khi bị tấn công tràn HELLO

MÔ PHỎNG “SPEED OF ADDING PERMANENT NEIGHBORS” Để so sánh tốc độ thiết lập khóa phiên khi sử dụng biện pháp bảo vệ LLSEC trước các cuộc tấn công của tràn HELLO hoặc ADAPTIVESEC, một trường hợp mô phỏng Cooja khác

64 được chạy Cấu trúc liên kết hiển thị trong Hình 4.13 được sử dụng, mỗi trong số 25 nút ghi lại số lượng các hàng xóm vĩnh viễn của nó và khởi động tại một thời điểm ngẫu nhiên trong

30 phút đầu tiên Với hai lần chạy liên tiếp, mỗi lần trong một giờ, tất cả các nút đã được định cấu hình để sử dụng (i) khả năng bảo vệ LLSEC chống lại các cuộc tấn công tràn HELLO với Bộ thông số 1, (ii) khả năng bảo vệ ADAPTIVESEC chống lại các cuộc tấn công tràn HELLO với Bộ thông số 3 Hai lần chạy này cũng được lặp lại với (i) không cho phép truyền lại và (ii) cho phép truyền lại Hình 4.14 cho thấy kết quả

Hình 4.13 Mô hình chạy mô phỏng “Speed Of Adding Permanent Neighbors”

Hình 4.14 (a) Không retransmissions, (b) Có retransmissions

Nhìn chung, tốc độ thêm hàng xóm vĩnh viễn không khác biệt nhiều giữa các hệ thống phòng thủ khác nhau Tuy nhiên, Bộ thông số 1 bị tụt lại phía sau Trong trường hợp không truyền lại, khả năng bảo vệ LLSEC chống lại các cuộc tấn công của tràn HELLO trở nên chậm hơn đáng kể, như thể hiện trong Hình 4.14a Điều này là do một vấn đề mà em đã đề cập - nếu ACK hoặc HELLOACK bị bỏ qua, những người hàng xóm dự kiến sẽ được giữ lại trong thời gian dài nếu 𝑇𝑎𝑐𝑘 dài, do đó khiến các HELLO đến từ những người hàng xóm dự kiến

65 bị bỏ qua trong một thời gian dài Cách khắc phục cho vấn đề này là truyền lại các khung, như thể hiện trong Hình 4.14b

Kết luận: Khả năng phục hồi của AKES đối với các cuộc tấn công của tràn HELLO phải đánh đổi bằng việc kéo dài cả 𝑇𝑎𝑐𝑘 và 𝑀𝑏𝑎𝑐 Một mặt, việc mở rộng 𝑇𝑎𝑐𝑘 có thể được chấp nhận nếu kích hoạt tính năng truyền lại, như thể hiện trong Hình 5c Mặt khác, việc mở rộng 𝑀𝑏𝑎𝑐 làm giảm sút nghiêm trọng trải nghiệm người dùng do việc thiết lập khóa phiên trở nên rất chậm Để so sánh, biện pháp phòng thủ ADAPTIVESEC chống lại các cuộc tấn công của tràn HELLO cũng bảo vệ chống lại các cuộc tấn công của tràn HELLO với thời lượng ngắn đối với 𝑇𝑎𝑐𝑘 và 𝑀𝑏𝑎𝑐 Ngoài ra, hệ thống phòng thủ ADAPTIVESEC bảo vệ khỏi bất kỳ số lượng nút nào do kẻ tấn công kiểm soát và dễ dàng định cấu hình hơn

MÔ PHỎNG “PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG YO-YO”

 COLLISION ATTACK Để so sánh hiệu quả của cách phòng thủ LLSEC trước các cuộc tấn công yo-yo và ADAPTIVESEC khi bị tấn công va chạm, một mô phỏng Cooja đã được thiết lập Trong mỗi lần chạy, mạng được hiển thị trong Hình 4.15 được chạy mô phỏng trong 1 giờ, trong đó tất cả 9 nút khởi động tại một thời điểm ngẫu nhiên trong 30 phút ảo đầu tiên Trong mỗi lần chạy, mỗi nút ghi lại số lượng HELLO, HELLOACK và ACK đã gửi của nó Trong lần chạy đầu tiên, không có cuộc tấn công nào được đưa ra làm cơ sở để so sánh Trong lần chạy thứ hai, các nút {1,2,4,5} chỉ nhận được HELLO, HELLOACK và ACK, do đó mô phỏng các cuộc tấn công va chạm trên bất kỳ frame khác Ngoài ra, trong lần chạy thứ ba, cùng một tập hợp các nút trên sẽ không nhận được HELLO từ các hàng xóm vĩnh viễn của chúng Đòn tấn công va chạm này vô hiệu hóa hiệu quả việc triệt tiêu các HELLO dư thừa của AKES Trong lần chạy thứ tư, nếu bất kỳ nút nào trong số các nút {1,2,4,5} vừa đặt lại Trickle, tức là I = Imin, nó hoàn toàn không nhận được HELLO Ý tưởng đằng sau cuộc tấn công xung đột này là trì hoãn việc thiết lập khóa phiên để khiến nhiều lần đặt lại Trickle thay vì chỉ một lần Ban đầu, tất cả các nút đều sử dụng Bộ thông số 4 và sau đó tất cả bốn lần chạy được lặp lại với Bộ thông số 5 và 6 Hình 4.16a đến 4.16d cho thấy kết quả

Hình 4.15 Mô hình chạy mô phỏng “Phòng Thủ Chống Lại Các Cuộc Tấn Công Yo-Yo”

Hình 4.16 Kết quả mô phỏng lần 1,2 (a) (b)

Hình 4.16 Kết quả mô phỏng lần 3,4 (c) (d) Đầu tiên chúng ta hãy xem số lượng HELLO đã gửi Nếu không có cuộc tấn công xung đột nào được khởi chạy, tương đối ít HELLO được gửi đi, bất kể bộ tham số được sử dụng là gì Điều này là do Trickle nghi ngờ rằng cấu trúc liên kết mạng ổn định và do đó làm giảm tỷ lệ HELLO Thêm rất nhiều HELLO được gửi đi khi gây nhiễu tất cả các khung ngoại trừ HELLO, HELLOACK và ACK vì điều này khiến AKES xóa các vùng lân cận vĩnh viễn, thiết lập lại các khóa phiên và có khả năng đặt lại Trickle Dự kiến, khả năng bảo vệ LLSEC chống lại các cuộc tấn công yo-yo sẽ giảm thiểu đáng kể các cuộc tấn công va chạm như vậy

ACK (Sending ACK) HELLOACK (Sending helloack) HELLO (broadcasting hello)

HELLOACK (Sending helloack) HELLO (broadcasting hello)

ACK (Sending ACK) HELLOACK (Sending helloack) HELLO (broadcasting hello)

HELLOACK (Sending helloack)HELLO (broadcasting hello)

CHẠY THỰC TẾ TRÊN THIẾT BỊ TEXAS INSTRUMENTS CC2538

4.3.1 GIỚI THIỆU VỀ THIẾT BỊ TI CC2538

CC2538 là bộ vi điều khiển không dây lý tưởng cho các ứng dụng ZigBee hiệu suất cao Thiết bị kết hợp hệ thống MCU dựa trên ARM Cortex-M3 mạnh mẽ với RAM trên chip lên đến 32KB và đèn flash trên chip lên đến 512KB với radio IEEE 802.15.4 mạnh mẽ Điều này cho phép thiết bị xử lý các ngăn xếp mạng phức tạp với bảo mật, các ứng dụng đòi hỏi khắt khe và tải xuống qua mạng 32 GPIO và thiết bị ngoại vi nối tiếp cho phép kết nối đơn

70 giản với phần còn lại của bo mạch Các bộ tăng tốc bảo mật phần cứng mạnh mẽ cho phép xác thực và mã hóa nhanh chóng và hiệu quả trong khi vẫn để CPU rảnh tay để xử lý các tác vụ ứng dụng Nhiều chế độ năng lượng thấp với tính năng duy trì cho phép khởi động nhanh từ chế độ ngủ và sử dụng năng lượng tối thiểu để thực hiện các tác vụ định kỳ Để phát triển suôn sẻ, CC2538 bao gồm một hệ thống gỡ lỗi mạnh mẽ và một thư viện trình điều khiển toàn diện Để giảm dung lượng flash của ứng dụng, ROM CC2538 bao gồm một thư viện chức năng tiện ích và một bộ tải khởi động nối tiếp Kết hợp với các giải pháp phần mềm Z- Stack toàn diện và mạnh mẽ của TI, CC2538 cung cấp giải pháp ZigBee có khả năng và đã được chứng minh nhất trên thị trường

Bảng 5.1: Một vài thông số tiêu biểu của CC2538

Peripherals USB, I2C, 2 SPI, 2 UART, 12-bit ADC 8- channel, 4 timers

Security Device identity, Debug security, Crypto acceleration (AES, SHA2, ECC, RSA)

4.3.2 KẾT QUẢ CHẠY THỰC TẾ

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG HIDDEN WORMHOLE ATTACKS

Thực hiện nạp code lên kit, và chạy mô phỏng mỗi lần trong 15 phút, sau đây là kết quả ghi nhận được:

Bảng 5.2: Kết quả chạy thực tế phòng thủ chống lại các cuộc tấn công hidden wormhole

Hardware testing Hidden Wormhole (Having collision attack)

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Hardware testing Hidden Wormhole (without collision attack)

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Kết luận: Kết quả chạy thực tế tương đương với kết quả từ mô phỏng Cuộc tấn công wormhole chỉ khiến các nút được kết nối qua lỗ sâu ẩn gửi nhiều HELLO, HELLOACK và ACK, trong khi các cuộc tấn công va chạm cũng khiến các nút khác của mạng nạn nhân gửi nhiều HELLO, HELLOACK và ACK

PHÒNG THỦ CHỐNG LẠI CÁC CUỘC TẤN CÔNG YO-YO ATTACKS

Thực hiện nạp code lên kit, và chạy mô phỏng mỗi lần trong 15 phút, sau đây là kết quả ghi nhận được:

Mô hình: 1 node bị ảnh hưởng – 1 node chạy bình thường

Bảng 5.3: Kết quả chạy thực tế phòng thủ chống lại các cuộc tấn công yo-yo

Lần chạy 1: không có cuộc tấn công nào được đưa ra làm cơ sở để so sánh

Hardware testing YOYO (Collision attack) 15minutes

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Lần chạy 2: 1 node chỉ nhận được HELLO, HELLOACK và ACK

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Lần 3: 1 node sẽ không nhận được HELLO từ các hàng xóm vĩnh viễn

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Lần 4: 1 node vừa đặt lại Trickle, nó sẽ hoàn toàn không nhận được HELLO

P4 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P5 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

P6 Số gói tin HELLO Số gói tin HELLOACK Số gói tin ACK

Kết luận: Khi sử dụng biện pháp LLSEC chống lại các cuộc tấn công yo-yo, chỉ ngăn chặn các cuộc tấn công va chạm khi kéo dài 𝑇𝑙𝑖𝑓 đến khoảng thời gian không mong muốn Biện pháp ADAPTIVESEC tỏ ra hiệu quả hơn trong phòng thủ, khi ko cần kéo dài 𝑇𝑙𝑖𝑓