Luận án Nghiên cứu, phát triển phương pháp phát hiện và xử lý tấn công hố đen vào giao thức định tuyến RPL

Nội dung text: Luận án Nghiên cứu, phát triển phương pháp phát hiện và xử lý tấn công hố đen vào giao thức định tuyến RPL

1. (False Positive Rate), tỷ lệ nhận gói tin thành công (PDR), độ trễ trung bình (E2ED), mức tiêu thụ năng lượng (PC). . Tỷ lệ phát hiện đúng (True Positive Rate - TPR) là tỷ lệ trường hợp dự đoán đúng, có tấn công và thực tế có tấn công. TP TPR = (3.1) TP+FN TP (True Positive) là trường hợp dự đoán có tấn công và thực tế có tấn công. Trường hợp FN (False Negative) là trường hợp dự đoán không có tấn công và thực tế có tấn công. . Tỷ lệ cảnh báo sai (False Positive Rate - FPR) là tỷ lệ trường hợp dự đoán sai, có tấn công và thực tế không có tấn công. FP FPR = (3.2) FP+TN FP (False Positive) là trường hợp dự đoán có tấn công và thực tế không có tấn công. TN (True Negative) là trường hợp dự đoán không có tấn công và thực tế cũng không có tấn công. . Tỷ lệ truyền gói tin thành công (PDR) biểu thị tỷ lệ các gói tin truyền thành công trên tổng số gói tin đã gửi. . Độ trễ trung bình (E2ED) đo thời gian cần thiết để gửi một gói tin từ nút đến DODAG root. . Mức tiêu thụ năng lượng (PC) cho các nút trong mạng thường sử dụng năng lượng thấp, nên nguồn năng lượng là một tài nguyên khan hiếm quan trọng đối với các mạng tổn hao năng lượng thấp. Công thức tính toán mức tiêu thụ năng lượng của mạng như sau: Energy (mJ) = (transmit *19.5 mA + listen * 21.8mA + CPU*1.8mA +LPM* 0.0545mA)*3V/4096*8 (3.3) Tại công thức 3.3 dựa vào hệ thống điều kiện của thiết bị Tmote Sky được cài đặt trong Contiki OS [60]. Phần cài đặt này, có 8 lần hoạt động trên mỗi giây (wakeups/second) khi không có lưu lượng truy cập trong mạng, radio vẫn hoạt động 0,6% thời gian. 3.7.3. So sánh kết quả thực nghiệm svBLOCK với RPL–Collect và SVELTE Trong phần này, tác giả đã thực hiện đánh giá so sánh svBLOCK với phương pháp SVELTE và RPL–Collect (without 6Mapper). Lý do, tác giả lựa chọn so sánh 84
2. 16 nút 25 nút 36 nút 100 80 60 40 Tỷ lệ phát hiệnđúng (%)Tỷphát lệ 20 0 30 60 90 120 150 180 Thời gian chạy (phút) Hình 3.15 Tỷ lệ phát hiện đúng (TPR) 5 16 nút 25 nút 36 nút 4.5 4 3.5 3 2.5 2 1.5 Tỷ lệ cảnh báosai (%) Tỷ cảnh lệ 1 0.5 0 30 60 90 120 150 180 Thời gian chạy (phút) Hình 3.16 Tỷ lệ cảnh báo sai (FPR) Trong hình 3.15 và 3.16, chúng ta nên lưu ý rằng, các kịch bản sau bao gồm số lượng nút giả mạo hố đen tăng lên, các nút này có thể được đặt gần nhau để tạo ra những ảnh hưởng nghiêm trọng cho mạng và do đó, làm cho việc phát hiện tấn công hố đen trở thành một nhiệm vụ khó khăn hơn. Thông qua các chỉ số trên, chúng ta có 86
3. đến đích được. Vì vậy, độ trễ trung bình sẽ không được phân tích ở đây tại bảng 3.4 có kết quả như sau: Bảng 3.4 So sánh kết quả thực nghiệm của PDR và PC giữa svBLOCK, RPL-Collect và SVELTE trong trường hợp mạng bị tấn công Kịch bản Các thông số svBLOCK RPL–collect SVELTE Tỷ lệ nhận gói tin (%) 78.9 39.3 36.7 16 nút Tiêu thụ năng lượng (mW) 0.82 0.71 0.78 Tỷ lệ nhận gói tin (%) 72.2 23.1 21.3 25 nút Tiêu thụ năng lượng (mW) 0.92 0.73 0.82 Tỷ lệ nhận gói tin (%) 60 14 13.8 36 nút Tiêu thụ năng lượng (mW) 1.02 0.76 0.92 Từ kết quả so sánh các tham số của các cơ chế khác nhau trên bảng 3.4, tác giả đã biểu thị thành các biểu đồ hình vẽ dưới đây. RPL-Collect SVELTE svBLOCK 100 80 60 40 Tỷ lệ nhận gói tin (%) tin gói Tỷnhận lệ 20 0 16 25 36 Số lượng nút Hình 3.17 Tỷ lệ nhận gói tin thành công 88
4. các nút cảm biến nhiều hơn. Vì vậy, năng lượng tiêu thụ của svBLOCK nhiều hơn so với các giải pháp khác. 3.7.3.2. Trong môi trường mạng bình thường Trong phần này, tác giả đã phân tích so sánh triển khai svBLOCK với các giải pháp khác nhau trong môi trường mạng bình thường. Mục đích thực hiện đánh giá svBLOCK để quan sát những hành vi hoạt động trong môi trường mạng bình thường khi không có nút tấn công giả mạo hố đen. Bởi vì, svBLOCK có khả năng phát hiện và cô lập nút tấn công hố đen. Tuy nhiên, dẫn đến phát sinh tỷ lệ cảnh báo sai có thể xảy ra vấn đề cô lập nút bình thường, ảnh hưởng đến hoạt động bình thường của mạng. Các kịch bản mô phỏng đều được chạy trong thời gian 180 phút và các kết quả so sánh chi tiết như sau: Chúng tôi quan sát thấy rằng, khi sử dụng danh sách đen (blacklist) cho phép svBLOCK làm giảm các nút tấn công giả mạo hố đen. Tuy nhiên, nó dẫn đến sự cố không mong muốn do kết quả tỷ lệ cảnh báo sai gây ra, tiêu tốn năng lượng và thời gian để giải quyết đồng thời làm gián đoạn hoạt động mạng tổn hao năng lượng thấp. Thông qua các kịch bản mô phỏng thực nghiệm svBLOCK đạt được 0% tỷ lệ cảnh báo sai (FPR) ngay cả khi phương pháp SVELTE đã đưa ra một số tỷ lệ cảnh báo sai tại hình 3.19. Trong trường hợp 36 nút, chúng ta thấy tỷ lệ cảnh báo sai của SVELTE là hơn 80%. Bởi vì, đối với tỷ lệ cảnh báo sai của phương pháp SVELTE liên quan trực tiếp đến việc phát hiện các nút tấn công hố đen và sự xuất hiện của chúng là do mất gói tin [11]. Rõ ràng là svBLOCK không gây ra vấn đề này cho mạng. 90 80 70 60 50 40 30 20 10 thôngphát hiện số sai(%) 0 16 25 36 Số lượng nút SVELTE svBLOCK Hình 3.19 Thông số phát hiện sai 90
5. 1400 RPL-Collect SVELTE svBLOCK 1200 1000 800 600 400 Độ trễ bình (ms) trung trễ Độ 200 0 16 25 36 Số lượng nút Hình 3.20 Độ trễ trung bình Trong hình 3.21, tác giả đo lường tỷ lệ truyền gói tin thành công (PDR) liên quan đến việc thực hiện các giải pháp khác nhau. Thật thú vị nhưng phải lưu ý rằng svBLOCK có tỷ lệ truyền gói tin thành công (PDR) là 94.1 % cao hơn so với RPL– Collect là 93.9 % trong kịch bản 16 nút. Tuy nhiên, quan sát như vậy không được ghi nhận đối với trong trường hợp 25 nút và 36 nút. Tức là tỷ lệ nhận gói tin của svBLOCK thấp hơn so với các giải pháp khác. Trong kịch bản 36 nút, svBLOCK chỉ đạt được 81.8% còn 87% đối với RPL–collect và SVELTE là 83.4%. Lý do tỷ lệ nhận gói tin thành công (PDR) của svBLOCK thấp hơn so với các giải pháp khác trong kịch bản 25 và 36 nút. Bởi vì, khi mạng trở nên dày đặc hơn, svBLOCK phải tạo ra nhiều bản tin hơn để cấu trúc liên kết DODAG lại, do đó khi số lượng gói bản tin tăng lên, điều này dẫn đến tắc nghẽn nút và chất lượng liên kết mạng thấp hơn. Liên quan đến mức tiêu thụ năng lượng trên mỗi nút đã được minh họa trong hình 3.26. Chúng ta có thể thấy rằng, giải pháp RPL–Collect đạt mức tiêu thụ năng lượng ít hơn so với các giải pháp khác trong cả 03 kịch bản. Chi phí tiêu thụ năng lượng tăng theo số lượng nút mạng. Như chi phí hoạt động thực hiện của svBLOCK là 1.18 mW xấp xỉ 17% và 47% so với giải pháp pháp SVELTE là 1.01 mW và RPL– Collect là 0.805 mW cho các mô hình mạng có 36 nút. Chúng ta lưu ý rằng, mức tiêu thụ năng lượng trong trường hợp mạng hoạt động bình thường trong hình 3.20–3.22. thì năng lượng cao hơn so với trường hợp mạng bị tấn công trong hình 3.17–3.18. Điều này là do nút tấn công có xu hướng loại bỏ tất cả các gói dữ liệu đi qua nút tấn công, dẫn đến giảm số lượng bản tin được nhận và xử lý bởi nút cha của nó. 92
6. 3.8. Những hạn chế của svBLOCK trong phát hiện và phòng chống dạng tấn công hố đen Thông qua việc phân tích nghiên cứu, phát triển các phương pháp phát hiện và phòng chống dạng tấn công hố đen với các kịch bản cụ thể trong mô hình giả lập, tác giả nhận thấy phương pháp phòng chống tấn công đã trình bày phía trên đạt hiệu quả tốt, có tính ứng dụng cao với độ chính xác vượt trội so với các phương pháp khác. Tuy nhiên, phương pháp vẫn còn tồn tại một số hạn chế sau: . Phương pháp phát hiện và phòng chống dạng tấn công hố đen kể trên mới giải quyết hiệu quả một lớp các kỹ thuật tấn công cụ thể, chứ chưa được mở rộng, phát triển để giải quyết nhiều kỹ thuật các dạng tấn công khác. . Do còn hạn chế về nhiều mặt nên giải pháp mới chỉ thực hiện mô phỏng trên các bộ công cụ giả lập với các thiết bị cảm biến quy mô nhỏ và vừa chưa. Phương pháp chưa được nghiên cứu, đánh giá chi tiết về tính hiệu quả khi triển khai trong môi trường thực tế với các mạng cực lớn. . Phương pháp được phát triển dựa trên ngôn ngữ lập trình C/C++ nên có thể sẽ có những khó khăn nhất định khi áp dụng trong thực tế với các ngôn ngữ lập trình khác. . Sau cùng, việc triển khai giải pháp phát hiện và phòng chống tấn công hố đen đã trình bày ở trên lên bất kỳ nút mạng nào cũng sẽ gây tiêu hao năng lượng của mạng, dù là không đáng kể. Tuy nhiên, để đảm bảo hiệu suất hoạt động của mạng, giải pháp nên được triển khai trên các nút mạng nên có cấu hình trung bình trở lên. Những điều cần lưu ý: svBLOCK dựa trên thuật toán mã hóa xác thực Salsa20-Poly1305 để bảo mật thông tin liên kết giữa DODAG root và các nút cảm biến trong mạng. Mặc dù svBLOCK có thể cung cấp tính bảo mật, tính toàn vẹn và tính sẵn sàng thông qua bản tin unicast, nhưng nó không đảm bảo xác thực thông qua các bản tin broadcast, gồm bản tin DIO và bản tin DIS. Điều này là do mỗi nút có một khóa được cấu hình trước riêng biệt, khóa này không được chia sẻ với các nút khác. Trong phần này, thuật toán Salsa20-Poly1305 được áp dụng để kiểm soát các bản tin điều khiển nhằm cách ly các nút giả mạo hố đen. Tuy nhiên, thuật toán này có thể được mở rộng để cung cấp xác thực cho các bản tin UDP, gửi một yêu cầu phản hồi điển hình sau mỗi 2 phút, trong khi các gói dữ liệu khác được gửi trong khoảng thời gian 10 giây. Phần so sánh mức tiêu thụ năng lượng được báo cáo trong các phần trước, chi phí năng lượng lên đến 0,03 mW liên quan đến chức năng thuật toán mã hóa xác thực Salsa20-Poly1305 là rất nhỏ. 94
7. giải pháp này cung cấp tính bảo mật, tính toàn vẹn và tính sẵn sàng cho các bản tin điều khiển bắt nguồn từ DODAG root. Các phần thử nghiệm được thực hiện trên Contiki OS với các kịch bản tấn công khác nhau. Phần kết luận đã chứng minh rằng, svBLOCK có thể đạt được tỷ lệ phát hiện chính xác cao hơn so các giải pháp giảm thiểu khác đã được báo cáo trong các tài liệu nghiên cứu trước đây. Phương pháp svBLOCK hiện đang nhắm mục tiêu phát hiện và phòng chống các nút giả mạo hố đen. Tuy nhiên, svBLOCK có thể được mở rộng thực hiện để giải quyết các cuộc tấn công nội bộ khác, gồm: Tấn công Selective Forwarding, tấn công wormhole Phương pháp svBLOCK phải được kết hợp với giải pháp VERA [27] để phòng chống các cuộc tấn công phiên bản và tấn công thứ hạng. Do đó, các hướng nghiên cứu trong tương lai tác giả sẽ tập trung vào việc mở rộng svBLOCK nhằm phát hiện và phòng chống cho các dạng tấn công khác nhau. Các thử nghiệm được thực hiện trên Contiki OS với số lượng nút và kịch bản tấn công khác nhau. Kết quả đã được chứng minh rằng, svBLOCK đạt tỷ lệ phát hiện đúng đến 98,5% với tỷ lệ cảnh báo sai là 3,7%. Về mức tiêu thụ năng lượng, cơ chế này tiêu hao năng lượng rất ít so với SVELTE. Hơn nữa, cơ chế cũng làm tăng tỷ lệ truyền gói tin thành công lên đến 47%. Do đó, svBLOCK là một giải pháp có thể được áp dụng để cung cấp bảo mật thông tin liên kết giữa các nút mạng nhằm phát hiện và phòng chống các cuộc tấn công hố đen. 96
8. Luận án là một công trình nghiên cứu có ý nghĩa về khoa học và thực tiễn. a) Về ý nghĩa khoa học: Luận án đã đóng góp thêm 06 công trình nghiên cứu (công trình nghiên cứu tại tạp chí khoa học – công nghệ, các hội thảo trong nước và hội thảo quốc tế). Những công trình này có tính mở để tiếp tục phát triển mở rộng các hướng nghiên cứu khác. . Nghiên cứu phân tích, cài đặt và đánh giá những ảnh hưởng của các dạng tấn công vào giao thức định tuyến RPL. . Đề xuất sử dụng Salsa20-Poly1305 trong mã hóa và xác thực thông điệp, đặc biệt các thông điệp điều khiển được gửi từ nút gốc trong RPL. . Đề xuất phương pháp phiện và phòng chống các dạng tấn công hố đen dựa trên svBLOCK. svBLOCK là có thể cô lập nút tấn công, hỗ trợ mạng có thể tái cấu trúc để khôi phục trạng thái hoạt động bình thường. b) Về nghĩa thực tiễn: Kết quả nghiên cứu của luận án đã đóng góp về an toàn thông tin trong mạng. Trong quá trình thực hiện nhiệm vụ đề tài nghiên cứu khoa học, tác giả đã tiến hành thử nghiệm mô phỏng để so sánh hiệu suất của phương pháp đề xuất so với các giải pháp phòng chống tấn công khác. Kết quả thu được ban đầu đã có hiệu quả khả quan đối với svBLOCK có thể phát hiện và cô lập, xử lý các dạng tấn công hố đen. 2. Kiến nghị Trong nghiên cứu này, tác giả đã tập trung vào phát triển phương pháp phát hiện và phòng chống các dạng tấn công hố đen. Do đây là một trong những dạng tấn công nguy hiểm ảnh hưởng đến hiệu suất mạng nên việc nghiên cứu áp dụng các phương pháp để phát hiện và phòng chống hiệu quả các cuộc tấn công vẫn còn là một thách thức đối với các nhà nghiên cứu. Chúng tôi tin rằng, cần có những nghiên cứu phân tích sâu hơn để đưa ra những phương pháp phòng chống tối ưu và hiệu quả hơn. Tuy nhiên, trong điều kiện thời gian nghiên cứu có hạn, tác giả đã có những đóng góp nhất định cho khoa học và thực tiễn đối với những nghiên cứu của mình. Trong thời gian tới, tác giả sẽ tiếp tục tập trung nghiên cứu phát triển và triển khai svBLOCK để phòng chống các dạng tấn công khác như: Tấn công sinkhole, tấn công tăng hạng, tấn công phiên bản và dạng tấn công chuyển tiếp chọn lọc để có thể đưa ra những đánh giá chính xác nhất về khả năng sử dụng của svBLOCK nhằm phát hiện và phòng chống các dạng tấn công vào giao thức định tuyến RPL. Trên cơ sở đó, chúng tôi xin kiến nghị, đề xuất Hội đồng tạo điều kiện giúp đỡ chúng tôi góp ý hoàn thiện và thông qua luận án. Xin chân thành cảm ơn! 98
9. TÀI LIỆU THAM KHẢO [1] Ancillotti, Emilio and Bruno, Raffaele and Conti, Marco (2013), “ The role of the RPL routing protocol for smart grid communications”, IEEE Communications Magazine, Vol.51, pp. 75-83. [2] A. Brandt (2012), “RPL: IPv6 routing protocol for low-power and lossy networks”, rfc, Vol.6550, pp. 1-157. [3] Mayzaud, Anthea and Badonnel, Remi and Chrisment, Isabelle (2016), “A Taxonomy of Attacks in RPL-based Internet of Things ”, International Journal of Network Security,Vol.18, pp. 459-473. [4] Tsvetkov, Tsvetko and Klein, Alexander (2011), “ RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks ”, Network, Vol.59, pp. 59-66. [5] T.Tsao, R. Alexander (2015), “A security threat analysis for the routing protocol for low-power and lossy networks (rpls) ”, RFC 7416, pp. 131. [6] Linus Wallgren, Shahid Raza, Thiemo Voigt (2013), “ Routing Attacks and Countermeasures in the RPL-Based Internet of Things ”, International Journal of Distributed Sensor Networks, Vol.9, pp. 794326. [7] Le, Anhtuan and Loo, Jonathan and Luo, Yuan and Lasebae, Aboubaker (2013), “A. The impacts of internal threats towards Routing Protocol for Low power and lossy network performance ”, In Proceedings of the 2013 IEEE Symposium on Computers and Communications (ISCC), pp. 000789-000794. [8] Xie, Weigao and Goyal, Mukul and Hosseini, Martocci, Jerald and Bashir, Yusuf and Baccelli, Emmanuel and Durresi, Arjan (2010), “ Routing loops in dag-based low power and lossy networks ”, 24th IEEE International Conference on Advanced Information Networking and Applications, pp. 888-895. [9] A. Mayzaud, A. Sehgal, Anuj and Badonnel (2014), “A study of RPL dodag version attacks ”, IFIP international conference on autonomous infrastructure, management and security, Springer, pp. 92-104. [10] P. Pongle (2015), “A Survey:Attacks on RPL and 6LoWPAN in IoT”, International Conference on Pervasive Computing (ICPC), pp. 1-6. [11] Raza, Shahid and Wallgren, Linus and Voigt, Thiemo (2013), “ SVELTE: Real- time intrusion detection in the Internet of Things”, Ad hoc networks, Vol.11, pp. 2661-2674. [12] Le, Anh tuan and Loo, Jonathan and Chai, K. Keong and Aiash, Mahdi (2016), “A specification-based IDS for detecting attacks on RPL-based network topology ”, Information, Vol.7, pp. 25. [13] Ioulianou, Philokypros and Vasilakis, Moscholios, Ioannis and Logothetis, Michael (2018), “A signature-based intrusion detection system for the Internet of Things ”, Information and Communication Technology Form. 100
10. [27] Dvir, Amit and Buttyan, Levente (2011), “VeRA-version number and rank authentication in rpl ”, 2011 IEEE Eighth International Conference on Mobile Ad- Hoc and Sensor Systems, pp.709-714. [28] M. Landsmann, M. Wahlisch, and T. C. Schmidt (2013), “Topology authentication in RPL ”, 2013 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp.73-74. [29] H. a. L. Perrey (2013), “TRAIL: Topology authentication in RPL”, arXiv preprint arXiv:1312.0984. [30] Glissa, Ghada and Rachedi, Abderrezak and Meddeb, Aref (2016), “A secure routing protocol based on RPL for Internet of Things”, 2016 IEEE Global Communications Conference (GLOBECOM), pp. 1-7. [31] Sehgal, Anuj and Mayzaud, Anth{\'e}a and Badonnel (2014), “Addressing DODAG inconsistency attacks in RPL networks”, 2014 Global Information Infrastructure and Networking Symposium (GIIS), pp.1-8. [32] Mayzaud, Anth{\'e}a and Sehgal, Anuj, Badonnel (2015), “Mitigation of topological inconsistency attacks in RPL-based low-power lossy networks”, International Journal of Network Management, Vol.25, pp.320-339. [33] Ghaleb, Baraq, A.Dubai (2018), “Addressing the DAO insider attack in RPL’s Internet of Things networks ”, IEEE Communications Letters, Vol.23, pp.68-71. [34] Verma, Abhishek and Ranga, Virender (2020), “Security of RPL based 6LoWPAN Networks in the Internet of Things: A Review”, IEEE Sensors Journal, Vol.20, pp. 5666-5690. [35] Lamaazi, Hanane and Benamar, Nabil and Jara, Antonio J (2018),“RPL-based networks in static and mobile environment: A performance assessment analysis ”, Journal of King Saud University-Computer and Information Sciences, Vol.20, pp. 320-333. [36] David and Gutierrez, Jairo A and Ray, S. Kumar (2019), “ SecTrust-RPL: A secure trust-aware RPL routing protocol for Internet of Things ”, Future Generation Computer Systems, pp. 860-876. [37] Apthorpe, Noah and Reisman, Dillon and Sundaresan, S. Narayanan (2017), “ Spying on the smart home: Privacy attacks and defenses on encrypted iot traffic ”, arXiv preprint arXiv:1708.05044. [38] Raza, Shahid and Duquennoy, Simon and H{\"o}glund, Joel and Roedig, Utz and Voigt, Thiemo (2014), "Secure communication for the Internet of Things—a comparison of link-layer security and IPsec for 6LoWPAN", Security and Communication Networks, vol. 7, pp. 2654 2668. [39] Turner (2011), "Transport Layer Security," IETF, no. RFC 6176. [40] Dierks (1999), "The transport layer security (TLS) protocol version 1.0", no. RFC 2246. 102
11. [55] Szalachowski, Pawel and Ksiezopolski, Bogdan and Kotulski, Zbigniew (2010), “CMAC, CCM and GCM/GMAC: Advanced modes of operation of symmetric block ciphers in wireless sensor networks”, Information Processing Letters,Vol.110, pp. 247-251. [56] Islam, M. Momtaz and Paul, Sourav and Haque, Md Mokammel (2017),“ Reducing network overhead of IoTDTLS protocol employing ChaCha20 and Poly1305 ”, pp.1-7. [57] Kharche (2016), "Node level energy consumption analysis in 6LoWPAN network using real and emulated Zolertia Z1 motes", IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS). [58] Polastre (2005), "Telos: enabling ultra-low power wireless research", in Proceedings of the 4th international symposium on Information processing in sensor networks, p. 48. [59] Raza, Shahid and Shafagh (2013), "Lightweight secure CoAP for the internet of things", IEEE Sensors Journal, vol. 13, pp. 3711 3720. [60] Dunkels, Adam and Schmidt, Oliver and Finne, Niclas and Eriksson, Joakim and {\"O}sterlind, Fredrik and Durvy, N.T. Mathilde (2011), “The contiki os: The operating system for the internet of things”, Online, at contikios. org,Vol.605. [61] Bernstein, Daniel J and Lange (2012), " The security impact of a new cryptographic library ", International Conference on Cryptology and Information Security in Latin America, pp. 159 176. [62] Bernstein, Daniel J and Van Gastel, Bernard and Janssen, Wesley and Lange, Tanja and Schwabe, Peter and Smetsers, Sjaak (2014), "TweetNaCl: A crypto library in 100 tweets", in International Conference on Cryptology and Information Security in Latin America, pp. 64 83. [63] Chugh, Karishma and Aboubaker (2012), " Case study of a black hole attack on LoWPAN-RPL ", in Proc. of the Sixth International Conference on Emerging Security Information, Systems and Technologies (SECURWARE), Rome, Italy (August 2012), pp. 157 162. 104