Giới thiệu

Một trong những tính năng quan trọng và then chốt nhất của các thiết bị được kết nối không dây là khả
năng cập nhật chương trình cơ sở của thiết bị qua mạng (còn gọi là OTA DFU). Bạn có thể hỏi "tại sao
tính năng này ngày càng trở nên phổ biến và được yêu cầu?" Chà, đó là do nhiều lý do chính đáng, một
số trong số đó là:

+ Nhu cầu ngày càng tăng của người dùng cuối đối với chức năng mới.

+ Để giải quyết các lỗi và lỗ hổng bảo mật (quan trọng và không quan trọng).

+ Vận chuyển sản phẩm ra thị trường nhanh hơn và có tùy chọn trì hoãn các tính năng có mức độ ưu
tiên thấp hơn và có thể triển khai chúng cho các thiết bị trong lĩnh vực này.

Như bạn có thể thấy, những lý do này (và nhiều lý do khác) làm cho OTA DFU trở thành một trong những
tính năng quan trọng và quan trọng nhất trong thiết bị được kết nối không dây.

Bluetooth Low Energy gần đây đã trở nên rất phổ biến, đặc biệt là trong các thiết bị đeo được, thiết bị y
tế, đèn hiệu và các thiết bị khác sử dụng điện thoại thông minh như một cách để giao tiếp với các thiết
bị nhỏ hạn chế về tài nguyên. Do đó, Bluetooth Low Energy đóng vai trò là một trong những phương tiện
phổ biến nhất để thực hiện OTA DFU cho các thiết bị được kết nối không dây. Thật không may, các tài
nguyên về chủ đề này rất khan hiếm, rất phân tán hoặc rất cụ thể đối với một nền tảng nhất định.

Vì vậy, tôi đặt mục tiêu thu thập tất cả các nguyên tắc và lý thuyết quan trọng đằng sau chủ đề này và
đưa tất cả chúng vào một bài đăng duy nhất.

Trong hướng dẫn này, chúng ta sẽ đi qua:

+ Cập nhật chương trình cơ sở thiết bị (DFU) là gì?

+ Cập nhật chương trình cơ sở thiết bị qua mạng (OTA DFU) là gì?

+ OTA DFU hoạt động như thế nào?

+ Vai trò của bộ nạp khởi động

+ Các bước cơ bản của OTA DFU

+ Thực tiễn tốt nhất trong việc triển khai OTA DFU

DFU (Cập nhật chương trình cơ sở của thiết bị) là gì?

Cập nhật chương trình cơ sở thiết bị (DFU) là một thao tác được sử dụng để cập nhật một phần hoặc
toàn bộ chương trình cơ sở trên thiết bị.

Trong hầu hết các trường hợp, DFU dựa vào sự tồn tại của bộ nạp khởi động. Bộ tải khởi động là một
đoạn mã tối thiểu chịu trách nhiệm:

+ Khởi chạy chương trình cơ sở hoặc hệ điều hành (OS) chính trong thiết bị.

+ Cung cấp khả năng cập nhật chương trình cơ sở hoặc hệ điều hành chính của thiết bị.

Nó thường được tối ưu hóa và giữ ở mức tối thiểu vì những lý do sau:
+ Để đảm bảo tác động tối thiểu đến thời gian khởi động.

+ Để đảm bảo các lỗi được giữ ở mức tối thiểu trong phần quan trọng này của chương trình cơ sở của
thiết bị. Bộ tải khởi động hiếm khi được cập nhật, vì vậy chúng cần phải mạnh mẽ (càng nhiều dòng mã
thường làm tăng khả năng xảy ra lỗi).

+ Kích thước của bộ tải khởi động ảnh hưởng đến dung lượng ROM còn lại cho chương trình cơ sở ứng
dụng.

Nói chung, các hoạt động chính của quy trình DFU bao gồm:

+ Cập nhật ứng dụng, ngăn xếp/HĐH (và đôi khi là cả bộ tải khởi động).

+ Xác minh tính xác thực của gói DFU.

+ Phòng ngừa hạ cấp.

+ Xác minh khả năng tương thích phần cứng.

+ Xác minh tính toàn vẹn của dữ liệu.

+ Giải mã dữ liệu được mã hóa.

+ Hỗ trợ cập nhật trên các phương tiện truyền tải khác nhau.

Một điều cần lưu ý là DFU đôi khi liên quan đến nhiều phần của hệ thống có thể được cập nhật tất cả
hoặc một phần với quy trình cập nhật chương trình cơ sở (ví dụ: bộ tải khởi động, RTOS/ngăn xếp và ứng
dụng).

Cập nhật chương trình cơ sở thiết bị qua mạng (OTA DFU) là gì?

OTA là viết tắt của cụm từ “Over-the-Air” và chỉ đơn giản đề cập đến thực tế là gói DFU được gửi đến
thiết bị đích/thiết bị cuối qua kết nối không dây. Trong trường hợp của chúng tôi, phương tiện không
dây là Bluetooth Low Energy. Đối với OTA DFU qua Bluetooth Low Energy, có ba phần chính:

+ Đóng gói hình ảnh DFU để chuyển sang thiết bị đích.

+ Thiết kế Dịch vụ GATT và Đặc điểm cần thiết để truyền hình ảnh DFU xuống thiết bị đích.

+ Tự thiết kế quy trình cập nhật chương trình cơ sở của thiết bị cho chipset mục tiêu sau khi thiết bị
nhận được hình ảnh DFU.

Các nhà cung cấp thường cung cấp triển khai #3 trên chipset mục tiêu cũng như các công cụ cần thiết
cho #1. Phần #2 là tùy chọn và đôi khi không được cung cấp bởi nhà cung cấp. Ngay cả khi phần này
được cung cấp bởi nhà cung cấp chipset, trong một số trường hợp, nhà thiết kế thiết bị đầu cuối có thể
muốn thiết kế triển khai của riêng họ.

Tại sao triển khai khả năng OTA DFU?

Mặc dù việc triển khai OTA DFU có thể/có vẻ như là một kỳ công khó khăn và phức tạp, nhưng nó có
những lợi ích rất quan trọng. Ngoài ra, với sự phổ biến của khả năng kết nối cho các thiết bị chạy bằng
pin và từ xa trong những năm gần đây, OTA DFU đã trở thành một yêu cầu của sản phẩm hơn là một
tính năng dễ có.

Một số lợi ích quan trọng nhất của OTA DFU bao gồm:

+ Thêm các tính năng mới vào sản phẩm cuối cùng.

+ Sửa các lỗi nghiêm trọng và giải quyết các lỗ hổng bảo mật.

+ Cắt giảm chi phí: việc thu hồi sản phẩm thường tốn kém hơn nhiều so với việc triển khai OTA DFU, đặc
biệt là trong các đợt triển khai sản phẩm lớn.

Như bạn có thể thấy, lợi ích của OTA DFU thường sẽ lớn hơn chi phí triển khai khả năng này trong sản
phẩm cuối cùng của bạn.

Đảm bảo quy trình OTA DFU mạnh mẽ và an toàn

Với việc giới thiệu OTA DFU, bạn đang đặt thiết bị của mình trước một vectơ tấn công mới. Với sự phổ
biến ngày càng tăng của khả năng OTA DFU trong các thiết bị IoT, nhiều thiết bị hiện đang tiếp xúc nhiều
hơn với các lỗ hổng và mối đe dọa bảo mật. Do đó, điều cực kỳ quan trọng là đảm bảo rằng quy trình
OTA DFU trên thiết bị của bạn rất mạnh mẽ và quan trọng nhất là an toàn.

Dưới đây là một số khía cạnh quan trọng nhất cần ghi nhớ khi thiết kế quy trình OTA DFU của bạn:

+ Bảo mật: mã hóa + xác minh danh tính (thông qua chữ ký số).

+ Đáng tin cậy: xác minh tính toàn vẹn + khôi phục lỗi.

+ Quản lý phiên bản: ngăn chặn rollback + hệ thống phiên bản.

OTA DFU hoạt động như thế nào?

Dưới đây là những điều cơ bản về cách thức hoạt động của quy trình cập nhật chương trình cơ sở thiết
bị (DFU) qua mạng:

Các bước cơ bản của quy trình OTA DFU

+ Hình ảnh chương trình cơ sở và tệp kê khai được mã hóa, ký và tải lên máy chủ cập nhật chương trình
cơ sở.

+ Thiết bị cuối truy vấn máy chủ cập nhật chương trình cơ sở và tìm nạp tệp kê khai và hình ảnh chương
trình cơ sở mới.
+ Gói sẽ được giải mã, xác thực và áp dụng.

Đây đơn giản là các bước chung và tùy thuộc vào chipset được sử dụng và thiết kế hệ thống, thường sẽ
có sự khác biệt trong cách triển khai của riêng bạn.

Ví dụ về quy trình xử lý OTA DFU

Hãy xem một ví dụ về quy trình DFU. Đây là một ví dụ từ tài liệu về quy trình DFU của Nordic:

Quy trình làm việc của quy trình Nordic nRF52 DFU

Một vài lưu ý về sơ đồ này:

+ Sơ đồ hiển thị các hoạt động và quy trình làm việc xảy ra trên thiết bị đích.

+ “Bộ điều khiển DFU” đề cập đến thiết bị kết nối với thiết bị BLE mục tiêu cần được cập nhật và chuyển
hình ảnh chương trình cơ sở sang. Đây có thể là điện thoại di động chạy ứng dụng hoặc nRF Connect
trên máy tính để bàn (thông qua nRF52 DK).

+ Thiết bị đích có thể đang chạy bộ tải khởi động ở chế độ DFU hoặc đang chạy ứng dụng có DFU chạy
ngầm.

+ Bộ điều khiển DFU kết nối với thiết bị đích và bắt đầu truyền hình ảnh DFU.

+ Thiết bị đích trước tiên sẽ nhận được một gói init mà nó xác thực (giai đoạn xác thực trước).

+ Gói init chứa thông tin quan trọng như loại hình ảnh, hàm băm của hình ảnh, phiên bản chương trình
cơ sở, phiên bản phần cứng, phiên bản được phép của SoftDevice và các thông tin khác.

+ Nếu gói init được xác thực, thì bộ điều khiển sẽ bắt đầu chuyển hình ảnh DFU tới mục tiêu.

+ Mục tiêu sẽ nhận được hình ảnh DFU đầy đủ và xác thực nó.

+ Khi hình ảnh DFU được xác thực, mục tiêu sẽ đặt lại và bộ tải khởi động sẽ kích hoạt hình ảnh DFU mới
để thay thế hình ảnh ban đầu.

+ Quá trình này có khả năng xử lý các bản cập nhật cho Bộ tải khởi động + SoftDevice + Ứng dụng tất cả
trong một gói. Các tập hợp con khác của sự kết hợp này cũng được cho phép, với một số ngoại lệ (bạn
có thể tìm thêm thông tin tại đây).

Các ví dụ khác về OTA DFU sử dụng Bluetooth Low Energy

Dưới đây là một số ví dụ tuyệt vời khác về triển khai OTA DFU:

+ mbed dịch vụ FOTA

+ Nâng cấp ST FOTA

+ BLE113 qua cập nhật không khí

Thực tiễn tốt nhất để triển khai OTA DFU

Thiết kế một quy trình OTA DFU có thể là một quá trình dài và đúng như vậy. OTA DFU là một hoạt động
rủi ro có thể phá vỡ chức năng của thiết bị hoặc khiến thiết bị dễ bị lỗ hổng bảo mật. Để giảm thiểu
những rủi ro này, cần phải tuân theo các thực hành tốt nhất.

Dưới đây là một số phương pháp hay nhất cần tuân theo khi thiết kế quy trình OTA DFU cho hệ thống
của bạn:

+ Digital Signing: chữ ký số đảm bảo tính xác thực của hình ảnh và tính toàn vẹn của dữ liệu trong hình
ảnh. Không có chữ ký, không có cách nào để xác minh rằng hình ảnh đến từ một nguồn xác thực và nó
có thể đến từ một bên thứ ba độc hại. Chữ ký điện tử cũng đảm bảo rằng dữ liệu trong hình ảnh không
bị sửa đổi (duy trì tính toàn vẹn) và nguyên vẹn/đầy đủ như được tạo tại nguồn/tác giả.

Mã hóa: mã hóa hình ảnh đảm bảo tính bảo mật của dữ liệu. Điều này làm cho không có bên trái phép
nào có thể xem nội dung của hình ảnh và hiểu ý nghĩa của nó. Chỉ thiết bị đầu cuối mới có thể giải mã
hình ảnh. Điều này đặc biệt đúng đối với các bản cập nhật qua mạng không dây vì dữ liệu sẽ dễ bị các
bên thứ ba đánh hơi kênh liên lạc được sử dụng để truyền hình ảnh. Các biện pháp bảo mật cũng phải
được áp dụng để bảo vệ bất kỳ phiên bản giải mã nào của hình ảnh được lưu trữ cục bộ trên thiết bị
cuối.

+ Bảo vệ kênh liên lạc: ngoài việc thực hiện các biện pháp bảo mật cần thiết để bảo vệ chính hình ảnh
DFU (tại nguồn và đích), cần thực hiện các biện pháp để bảo mật kênh liên lạc mà hình ảnh DFU được
truyền qua. Tùy thuộc vào công nghệ truyền thông được sử dụng, có các cấu hình và triển khai khác
nhau để đảm bảo kênh truyền thông được an toàn. Các ví dụ bao gồm sử dụng Bluetooth LE Secure
Connections (yêu cầu phiên bản 4.2 trở lên), TLS, v.v.

Hãy nhớ rằng các kênh liên lạc không phải lúc nào cũng không dây và có thể liên quan đến việc chuyển
nội bộ hệ thống, chẳng hạn như từ SoC sang đèn flash bên ngoài. Điều này có thể gây ra mối đe dọa bảo
mật nếu một bên độc hại có quyền truy cập vật lý vào thiết bị đầu cuối.

+ Phiên bản: một trong những biện pháp bảo mật cần được áp dụng là đảm bảo rằng không thể thực
hiện cập nhật DFU với phiên bản phần sụn cũ hơn. Để đạt được điều này, một hệ thống lập phiên bản
phải được thiết lập cho phép chỉ các phiên bản mới hơn được cài đặt.

+ Khả năng khôi phục: một quy trình cần được đưa ra để khôi phục các lỗi trong các giai đoạn khác nhau
của quy trình DFU. Điều này bao gồm xử lý các tình huống như mất điện, hỏng dữ liệu, hình ảnh DFU bị
thao túng, v.v. và có thể khôi phục chương trình cơ sở về hình ảnh ban đầu.

+ Ghi nhật ký và báo cáo trạng thái: Bạn nên ghi nhật ký các hoạt động và trạng thái của chúng trong các
quy trình DFU trong suốt vòng đời của sản phẩm. Các nhật ký này có thể được báo cáo cho các thiết bị
khác trong hệ thống (chẳng hạn như cổng, máy chủ đám mây, v.v.) cho mục đích giám sát từ xa. Chúng
có thể hữu ích cho mục đích gỡ lỗi hoặc để hiểu rõ hơn về nguyên nhân gây ra lỗi có thể xảy ra trong
DFU.

+ Cập nhật kịp thời: đảm bảo cập nhật kịp thời có thể rất quan trọng đối với một số hệ thống nhất định
hoặc trong các tình huống cụ thể, chẳng hạn như khi lỗ hổng bảo mật được phát hiện. Trong trường hợp
này, nhà sản xuất muốn đảm bảo rằng tất cả các thiết bị trong trường đều được cập nhật càng sớm càng
tốt.

+ Giảm thiểu thời gian ngừng hoạt động: tùy thuộc vào ứng dụng, một số chức năng hệ thống có thể rất
quan trọng và cần phải khả dụng ngay cả trong quá trình vận hành DFU.

+ Nhận thức của người dùng: Thông lệ tốt là làm cho người dùng biết về một bản cập nhật có sẵn. Điều
này giúp đảm bảo người dùng thực hiện cập nhật trong các trường hợp gần như tối ưu (ví dụ: được kết
nối với nguồn điện, đủ mức pin, ít bị gián đoạn chức năng và khả năng sử dụng của thiết bị đầu cuối,
v.v.). Nó cũng có thể giúp đẩy nhanh quá trình bắt đầu cập nhật trong trường hợp bản cập nhật giải
quyết các lỗ hổng hoặc lỗi phần mềm (người dùng được khuyến khích thực hiện/cho phép cập nhật hơn
nếu họ biết các sự cố sẽ được khắc phục bằng bản cập nhật).

+ Sử dụng bộ xử lý mã hóa được tăng tốc phần cứng để tăng tốc hoạt động mã hóa (ví dụ: trong các ứng
dụng quan trọng về thời gian, ứng dụng hạn chế bộ nhớ).

+ Tích hợp bộ xử lý mật mã an toàn vào hệ thống của bạn khi khả thi (ví dụ: trong các ứng dụng quan
trọng về an toàn, ứng dụng quan trọng về thời gian, ứng dụng hạn chế bộ nhớ).
Giới thiệu về OTA DFU trên nRF52

SDK nRF cung cấp một số triển khai ví dụ về bộ nạp khởi động, mỗi bộ cho một phương tiện truyền tải
khác nhau (BLE, USB, UART, v.v.). Bộ tải khởi động được sử dụng để khởi chạy ứng dụng chính và trong
một số trường hợp, chuyển đổi giữa nhiều ứng dụng có trong phần sụn và cũng được sử dụng để khởi
chạy thiết bị trước khi tải ứng dụng.

Đây là sơ đồ hiển thị kiến trúc của các mô-đun bộ tải khởi động nRF:

Các mô-đun khác nhau là:

+ nrf_bootloader: mô-đun bộ nạp khởi động chịu trách nhiệm kích hoạt phần sụn mới, khởi động vào
ứng dụng, cung cấp cho cơ quan giám sát và vào chế độ DFU cho phép nhận phần sụn mới.

+ nrf_crypto: thư viện mật mã chịu trách nhiệm chạy các hoạt động mã hóa cần thiết để triển khai các
bản cập nhật chương trình cơ sở an toàn.

+ nrf_dfu: mô-đun cung cấp các khả năng Cập nhật phần sụn thiết bị (DFU) phổ biến trên các phương
tiện truyền tải được hỗ trợ khác nhau.

+ nrf_dfu_transport: lớp trung gian xác định giao diện chung phải được triển khai bởi từng lớp vận
chuyển.

Các mô-đun truyền tải khác nhau triển khai các hoạt động dành riêng cho truyền tải (BLE, USB, UART,
v.v.).

Bộ tải khởi động an toàn nRF BLE

Bộ tải khởi động an toàn nRF BLE thực hiện các biện pháp bảo mật để bảo vệ quy trình DFU khỏi các bên
độc hại. Nó sử dụng các mô-đun Bootloader và DFU để triển khai bộ tải khởi động với chức năng DFU an
toàn. Bộ tải khởi động được tải vào một phần chuyên dụng của bộ nhớ flash tách biệt với Thiết bị mềm
và Ứng dụng. Nó cũng sẽ nằm trong dự án Segger Embedded Studio (SES) của riêng nó, được biên dịch
riêng và tải lên thiết bị đích.

Lưu ý: Bộ tải khởi động an toàn nRF BLE phụ thuộc vào hoạt động của SoftDevice cho BLE, vì vậy
SoftDevice phải có trên thiết bị trước khi thực hiện thao tác DFU.

Đây là sơ đồ chi tiết hiển thị vị trí của các thành phần khác nhau trong bộ nhớ flash:
Các phần khác nhau là:

+ Phần Bộ tải khởi động DFU:

Cài đặt bộ nạp khởi động

Lưu trữ tham số MBR

bộ nạp khởi động

+ Phần ứng dụng:

Dữ liệu ứng dụng

Đăng kí

+ thiết bị mềm
+ MBR (Bản ghi khởi động chính)

Chế độ DFU

Khi bộ tải khởi động ở chế độ DFU, nó sẽ kích hoạt mô-đun vận chuyển DFU BLE và thiết bị sẵn sàng
nhận phần sụn mới. Bộ tải khởi động sẽ chuyển sang chế độ DFU nếu một trong các trường hợp sau xảy
ra:

+ Không có ứng dụng hợp lệ nào trong bộ nhớ flash.

+ Khi có một SoftDevice và ứng dụng hợp lệ, nó sẽ được kích hoạt bởi một trong các thao tác sau:

Nút được xác định trước được nhấn (được xác định bởi
NRF_BL_DFU_ENTER_METHOD_BUTTON)

Sự kiện đặt lại mã pin (được xác định bởi NRF_BL_DFU_ENTER_METHOD_PINRESET)

Một giá trị đặc biệt có trong thanh ghi GPREGRET (NRF_BL_DFU_ENTER_METHOD_GPREGRET)

Yêu cầu từ ứng dụng được ghi vào trang cài đặt (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS)

Sau khi vào chế độ DFU, bộ hẹn giờ không hoạt động sẽ bắt đầu. Khi bộ đếm thời gian này hết hạn, bộ
tải khởi động sẽ đặt lại. Bộ đếm thời gian trên bất kỳ hoạt động DFU nào.

Kích hoạt chương trình cơ sở

Đây là bước cuối cùng của quá trình cập nhật firmware. Nó được kích hoạt dựa trên các cài đặt được lưu
trữ trong phần cài đặt được hiển thị ở trên trong bố cục bộ nhớ.

Nó liên quan đến việc sao chép chương trình cơ sở mới để thay thế chương trình cơ sở cũ (bản cập nhật
Single Bank) hoặc chuyển sang chạy chương trình cơ sở mới được đặt ở một vị trí riêng biệt của chương
trình cơ sở gốc (bản cập nhật Dual Bank).

Khi phần sụn mới thay thế phần sụn cũ, cài đặt bộ tải khởi động được cập nhật để cho phép hình ảnh
phần sụn mới khởi động.

trình tự khởi động

Dựa trên các cài đặt được lưu trữ trong trang cài đặt bộ tải khởi động, bộ tải khởi động sẽ xác định: liệu
ứng dụng có tồn tại hay không và vị trí của ứng dụng đó. Bộ tải khởi động an toàn thực hiện xác minh
chữ ký của ứng dụng trước khi khởi động vào nó.

Dưới đây là các bước khởi động diễn ra từ khi đặt lại đến khi khởi động ứng dụng:

+ Đầu tiên, MBR được khởi động.

+ MBR tra cứu vị trí của bootloader.

+ Nếu một bộ tải khởi động được tìm thấy, nó sẽ được điều hành bởi MBR.

+ Bộ tải khởi động an toàn (1) sử dụng các thao tác mã hóa để xác minh chữ ký của chương trình cơ sở
(Tính xác thực) và (2) rằng nó không bị hỏng (Tính toàn vẹn của dữ liệu). Điều này được thực hiện trong
hai trường hợp: khi khởi động và khi nhận được hình ảnh chương trình cơ sở mới.
+ Nếu không tìm thấy bộ tải khởi động, MBR sẽ khởi động hình ảnh theo sau nó (MBR) tại địa chỉ 0x1000
(SoftDevice).

+ SoftDevice sau đó khởi động ứng dụng.

Có bốn chế độ xác nhận khởi động khác nhau có thể được cấu hình.

+ Xác thực chữ ký (ECDSA) – kiểm tra tính toàn vẹn và an toàn nhất của dữ liệu.

+ Xác thực hàm băm (SHA-256) – kém bảo mật hơn và kiểm tra tính toàn vẹn của dữ liệu.

+ Xác thực CRC (CRC32) – không bảo mật, chỉ kiểm tra tính toàn vẹn của dữ liệu.

+ Không xác thực – không bảo mật, không kiểm tra tính toàn vẹn.

Điều này được cấu hình như một phần của gói cập nhật chương trình cơ sở. Nếu chế độ chữ ký được chỉ
định, thì chữ ký sẽ tồn tại trong gói. Để xác thực hàm băm và CRC, thông báo mật mã được tạo trên chip
và ghi vào flash khi áp dụng bản cập nhật.

Lưu ý quan trọng: xác thực khởi động độc lập với quy trình xác thực cập nhật chương trình cơ sở. Điều
này có nghĩa là gói cập nhật được ký bất kể chế độ khởi động an toàn có trong đó. Điều này đảm bảo
rằng hệ thống được bảo vệ khỏi các bản cập nhật chương trình cơ sở trái phép ngay cả khi không có xác
nhận khởi động.

Quá trình cập nhật chương trình cơ sở thiết bị (DFU)

Quá trình DFU có thể được chạy bằng cách sử dụng một trong các công cụ Bắc Âu sau. Mỗi công cụ này
được sử dụng để gửi gói DFU đến thiết bị đích để thực hiện cập nhật.

+ Công cụ dòng lệnh nrfutil

+ nRF Connect cho máy tính để bàn

+ nRF Connect cho di động

Hai thiết bị tham gia vào quá trình DFU: bộ điều khiển DFU truyền gói DFU và mục tiêu DFU nhận và áp
dụng gói DFU.

Đây là sơ đồ mà chúng ta đã xem trong bài trước, sơ đồ này cho thấy quy trình làm việc của quy trình
DFU:
Công cụ dòng lệnh nrfutil được sử dụng để tạo gói DFU được bộ điều khiển DFU chuyển đến mục tiêu
DFU. Gói cập nhật chứa:

+ gói tin ban đầu

+ Dữ liệu nhị phân (bất kỳ sự kết hợp nào của Bootloader + SoftDevice + Application)

Dưới đây là các bước cơ bản liên quan đến quy trình DFU:

+ Gói init được chuyển đến mục tiêu DFU trước.

+ Mục tiêu sau đó xác thực gói init.

+ Nếu gói init được xác thực thành công, thì bộ điều khiển DFU sẽ chuyển dữ liệu nhị phân.
+ Mục tiêu sau đó xác thực sau dữ liệu nhị phân.

+ Nếu mục tiêu xác thực nhị phân thành công, thì nó sẽ đặt lại.

+ Sau khi đặt lại, bộ tải khởi động sẽ kích hoạt hình ảnh phần sụn mới.

Gói DFU sẽ chứa hai bản cập nhật nếu cả SoftDevice và Ứng dụng đều được cập nhật. Quá trình này diễn
ra liền mạch đối với người dùng cuối và được coi là một bản cập nhật duy nhất (mặc dù trên thực tế, đó
là hai bản cập nhật).

Gói khởi tạo

Phần tệp kê khai của hình ảnh DFU (được gọi là gói init theo thuật ngữ nRF) phải được ký để bảo vệ
chống lại các bên độc hại đang cố mạo danh tác giả xác thực của hình ảnh DFU.

Bộ tải khởi động an toàn sử dụng thư viện mật mã (nrf_crypto) để thực hiện các hoạt động mã hóa cần
thiết khác nhau nhằm xác thực gói init. Các chương trình phụ trợ khác nhau có sẵn để sử dụng trong bộ
tải khởi động (chúng tôi sẽ sử dụng chương trình phụ trợ micro-ecc, đây là thư viện bên thứ ba nguồn
mở có sẵn trên GitHub).

Gói init chứa các trường khác nhau mô tả nội dung của gói DFU. Đây là một bảng (lấy từ tài liệu của
Nordic) hiển thị tất cả các trường trong gói init:

Ngoài việc xác thực chữ ký, gói init cũng được xác minh để đảm bảo rằng nó tương thích với thiết bị,
phần sụn và phần cứng hiện tại. Các bước khác nhau của quy trình xác thực được thực hiện theo thứ tự
sau:

+ Chữ ký của gói tin, chữ ký.

 Để có thể xác minh chữ ký, mã xác thực cần khóa chung tương ứng với khóa riêng được sử dụng
để ký gói init.

Khóa này nằm trong tệp dfu_public_key.c.

+ Loại chương trình cơ sở, fw_type.

+ Phiên bản phần cứng, hw_version.

+ Phiên bản SoftDevice, sd_req.

+ Phiên bản chương trình cơ sở, fw_version.

+ Kích thước chương trình cơ sở để xem liệu bản cập nhật có phù hợp hay không.

Chữ ký được tạo bằng khóa riêng mà bạn tạo bằng công cụ dòng lệnh nrfutil (trước khi tạo gói DFU).
Khóa riêng này cần được bảo vệ và giữ bí mật khỏi các bên độc hại.

Bộ tải khởi động chỉ chứa một bản sao của khóa chung, được sử dụng để xác minh chữ ký được tạo bởi
khóa riêng được liên kết.

Dịch vụ nRF DFU BLE GATT

Dịch vụ GATT được triển khai như một phần của mô-đun DFU Bảo mật Bắc Âu được gọi là Dịch vụ DFU
Bảo mật. Đó là một UUID 16-bit được đăng ký với Bluetooth SIG với giá trị 0xFE59. Đó là một dịch vụ
chính độc lập không phụ thuộc vào bất kỳ dịch vụ nào khác. Điều này được triển khai ở phía mục tiêu
DFU (Máy chủ GATT) và tiếp xúc với bộ điều khiển DFU (Máy khách GATT).

Nó chứa các Đặc điểm sau:

+ Điểm kiểm soát DFU

UUID: 0x8EC90001-F315-4F60-9FB8-838830DAEA50

Quyền: Viết, Thông báo

+ Gói DFU

UUID: 0x8EC90002-F315-4F60-9FB8-838830DAEA50

Quyền: Viết mà không cần phản hồi, Thông báo

Yêu cầu bảo mật (mã hóa) không bắt buộc đối với dịch vụ, tuy nhiên, việc triển khai nó được khuyến
nghị để cung cấp bảo mật cao hơn.

Đặc điểm điểm kiểm soát DFU

Đặc điểm Điểm kiểm soát DFU được sử dụng để kiểm soát trạng thái của quy trình DFU. Các hoạt động
DFU được bắt đầu bằng cách ghi vào đặc điểm này.

Khi kết thúc quá trình DFU, một thông báo sẽ được gửi lại cho bộ điều khiển DFU để báo cáo trạng thái
của bản cập nhật. Bộ điều khiển DFU chịu trách nhiệm theo dõi tiến trình cập nhật.

Đặc điểm gói DFU

Đặc tính Gói DFU được sử dụng để truyền dữ liệu DFU từ bộ điều khiển DFU sang mục tiêu DFU.

Truyền gói khởi tạo DFU

Đầu tiên, gói init được gửi đến mục tiêu DFU. Khi nó đã được xác minh là được chuyển thành công, bộ
điều khiển DFU sẽ đưa ra lệnh để bắt đầu xác thực gói init.

Truyền dữ liệu DFU

Khi gói init đã được xác thực thành công, hình ảnh phần sụn được chia thành nhiều phần để được
chuyển đến mục tiêu DFU. Nếu hoạt động truyền bị tạm dừng tại bất kỳ thời điểm nào (ví dụ: do mất
điện), quy trình DFU có thể tiếp tục từ đoạn dữ liệu hợp lệ cuối cùng đã nhận được.

Khi tất cả các khối dữ liệu đã được chuyển thành công, bộ điều khiển DFU sẽ đưa ra lệnh kiểm tra CRC
để xác minh tính toàn vẹn của dữ liệu. Nếu kiểm tra CRC vượt qua, thì bộ điều khiển DFU sẽ đưa ra lệnh
để kích hoạt bản cập nhật chương trình cơ sở thực tế.

DFU không nút

Ví dụ về BLE Secure DFU Bootloader có trong SDK phụ thuộc vào việc nhấn một nút (Nút 4 trên
nRF52840 DK) trong khi khởi động để chuyển sang chế độ DFU và có thể bắt đầu quá trình OTA DFU.

Tuy nhiên, trong sản xuất và trên thực tế, một “DFU không có nút” có lẽ có ý nghĩa hơn. Điều này cho
phép bạn hiển thị Dịch vụ DFU GATT cùng với Dịch vụ GATT của ứng dụng và có thể chuyển sang chế độ
DFU từ bên trong Ứng dụng đang chạy trên thiết bị của bạn.