search

BluezoneGlobal / documents

6 stars 11 forks source link

Về việc thu và sử dụng địa chỉ MAC cố định. #3

Closed phanduonghieu closed 4 years ago

phanduonghieu commented 4 years ago

Trong whitepaper một kỹ thuật được nhấn mạnh là việc lấy địa chỉ MAC cố định.

Phần 6.1 viết: Tại sao chúng tôi lại không sinh ra nhiều Bluezone ID thay vì chỉ sử dụng 1 mã duy nhất? Chúng tôi cho rằng việc sinh mã thay đổi liên tục không giúp cho việc ẩn danh tốt hơn. Khi điện thoại bật Bluetooth đồng nghĩa với việc sẽ có 2 loại tín hiệu được phát ra là Bluetooth Classic và BLE. Với tín hiệu Bluetooth Classic quảng bá sẽ luôn gắn với 1 địa chỉ MAC cố định của điện thoại từ khi xuất xưởng. Như vậy, bản chất điện thoại đã thực hiện quảng bá ra 1 ID cố định qua Bluetooth Classic. Chúng tôi cũng đã có những trao đổi với nhóm của Apple và Google về vấn đề của Bluetooth Classic, hi vọng dự án hợp tác giữa Apple và Google có thể sớm đưa ra chuẩn Bluetooth mới. Khi đó chúng tôi sẽ sử dụng phần sinh ID ngẫu nhiên của Apple/Goolge vì lúc đó ID ngẫu nhiên mới có ý nghĩa.

Phần 7.1 viết: Việc có được địa chỉ MAC của các thiết bị Bluetooth classic không cài Bluezone có thể giúp truy vết những F0 không sử dụng Bluezone. Đây cũng là điểm hiệu quả hơn so với những giải pháp hiện có.

Có 2 vấn đề ở đây: I) Về kỹ thuật : Việc lấy địa chỉ MAC cố định là không dễ khi ở chế độ non-discoverable - là chế độ thường xuyên của các điện thoại dù có bật Bluetooth, cũng bởi lý do an toàn. Việc cố tình tìm cách lấy địa chỉ MAC cố định khi ở chế độ non-discoverable có thể được coi là một tấn công nghe lén, và không thể dễ cài vào app. Do vậy, có lẽ việc lấy địa chỉ MAC cố định được nói tới chỉ là khi thiết bị ở chế độ discoverable, là trường hợp không phổ quát, và do vậy không thể thay thế việc sinh ra nhiều Bluezone ID.

II) Về mặt ethics: việc tự ý lấy địa chỉ MAC của các thiết bị Bluetooth classic không cài Bluezone là không thể được. Nó không khác gì việc cài công cụ nghe lén vào app. Nếu 1 người đã không muốn tham gia vào Bluezone thì không thể thu thập thông tin từ máy của họ với bất cứ lý do gì. Việc bảo vệ không lộ địa chỉ MAC cố định là một vấn đề an toàn các hãng đang cố bảo vệ người dùng, không có lý do gì chúng ta lại tự hào với việc dùng app để lấy địa chỉ MAC cố định của một người không tham gia cài app.

Tôi rất hoan nghênh việc công khai whitepaper và codes. Đặc biệt hoan nghênh tinh thần của chính phủ thể hiện qua phát biểu của Bộ trưởng “Ứng dụng Bluezone là một bước tiến mới, có tính đột phá trong việc sử dụng công nghệ để phòng chống dịch. Đột phá ở chỗ, chính quyền không thu thập thông tin của người dân, các thông tin chỉ được lưu trên máy điện thoại của cá nhân.” (Cf. https://www.nhandan.com.vn/khoahoc-congnghe/item/44133602-ung-dung-bluezone-dot-pha-trong-su-dung-cong-nghe-chong-dich-covid-19.html)

Để phù hợp với tinh thần trên, tôi đề nghị : Làm giống như tất cả các thiết kế của thế giới: sinh ra nhiều ID ngẫu nhiên cho mỗi máy. Bước sau đó nên tiến tới thay đổi để theo đúng tinh thần « thông tin chỉ lưu trên mỗi máy cá nhân khi họ không nhiễm bệnh » thì việc sinh các ID ngẫu nhiên này cần do bản thân máy cá nhân tự sinh chứ không cần phải được cấp. Bỏ việc thu thập thông tin các máy của người dùng không liên quan. Chúng ta cần phân biệt cái có thể làm được về mặt kỹ thuật, và cái không được phép làm về mặt nguyên tắc. Việc thu thập thông tin về 1 thiết bị cá nhân của người dùng mà không được họ cho phép là vi phạm các nguyên tắc bảo mật dữ liệu, chẳng hạn GDPR, và tạo hình ảnh không tốt khi chúng ta chủ động quảng bá sản phẩm ra quốc tế.

Tôi nhận định việc thay đổi để theo đúng tinh thần đã công bố sẽ nhận được sự tin tưởng và đón nhận của người dùng. Đó là cơ sở để ứng dụng được nhiều người tham gia, ít nhất từ 30%-60% - điều kiện cần để ứng dụng trở thành hữu ích trong việc phòng chống lây lan của Covid.

thaidn commented 4 years ago

+1 ý kiến @phanduonghieu.

Bổ sung một số thông tin tôi thấy trong mã nguồn:

1/ Về chuyện discoverable vs non-discoverable, có thể xem thêm ở https://github.com/BluezoneGlobal/react-native-bluetooth-scan/issues/4.

Code quét Bluetooth Classic trên Android như sau: https://github.com/BluezoneGlobal/react-native-bluetooth-scan/blob/master/lib/android/src/main/java/com/scan/ServiceTraceCovid.java#L658-686

Dòng 672 sử dụng API [startDiscovery](https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#startDiscovery()) của BluetoothAdapter: https://github.com/BluezoneGlobal/react-native-bluetooth-scan/blob/master/lib/android/src/main/java/com/scan/ServiceTraceCovid.java#L672

Tài liệu của startDiscovery nhấn mạnh như thế này:

Device discovery will only find remote devices that are currently discoverable (inquiry scan enabled). Many Bluetooth devices are not discoverable by default, and need to be entered into a special mode.

2/ Nếu thấy cái thiết bị Bluetooth Classic, Bluezone sẽ ghi vào database tên thiết bị, địa chỉ MAC và thời gian thấy thiết bị.

Code làm việc này trên Android ở đây: https://github.com/BluezoneGlobal/react-native-bluetooth-scan/blob/master/lib/android/src/main/java/com/scan/ServiceTraceCovid.java#L766-785.

Database này sẽ được backup ra external storage. Các app khác có quyền đọc external storage cũng có thể thấy dữ liệu này.

BkavMS17 commented 4 years ago

Cảm ơn @phanduonghieu đã quan tâm và đóng góp ý kiến với bluezone

Do vậy, có lẽ việc lấy địa chỉ MAC cố định được nói tới chỉ là khi thiết bị ở chế độ discoverable, là trường hợp không phổ quát, và do vậy không thể thay thế việc sinh ra nhiều Bluezone ID.

Chỗ này có lẽ bạn đã hiểu nhầm về ý của mục 6.1 trong Whitepaper. Bluezone vẫn sinh ID cho mỗi người dùng chứ không dùng địa chỉ MAC để thay cho Bluezone ID. Ý của team phát tiển là do Bluetooth Classic quảng bá sẽ luôn gắn với 1 địa chỉ MAC cố định của điện thoại từ khi xuất xưởng. Như vậy, bản chất điện thoại đã thực hiện quảng bá ra 1 ID cố định qua Bluetooth Classic, nên việc sinh ID ngẫu nhiên không làm ẩn danh tốt hơn. Nhóm cũng không nói là không có ý định sinh ID ngẫu nhiên, Bluezone sẽ sử dụng ID ngẫu nhiên khi nó có ý nghĩa. Cụ thể trong whitepaper đã nói rằng nhóm có những trao đổi với nhóm của Apple và Google về vấn đề của Bluetooth Classic, hi vọng dự án hợp tác giữa Apple và Google có thể sớm đưa ra chuẩn Bluetooth mới. Khi đó Bluezone sẽ sử dụng phần sinh ID ngẫu nhiên của Apple/Goolge vì lúc đó ID ngẫu nhiên mới có ý nghĩa. Hiện tại nhóm vẫn đang tích cực làm việc cùng với đội phát triển API của Apple và GG để thúc đẩy việc sử dụng ID ngẫu nhiên hiệu quả và có ý nghĩa hơn.

Về mặt ethics: việc tự ý lấy địa chỉ MAC của các thiết bị Bluetooth classic không cài Bluezone là không thể được. Nó không khác gì việc cài công cụ nghe lén vào app. Nếu 1 người đã không muốn tham gia vào Bluezone thì không thể thu thập thông tin từ máy của họ với bất cứ lý do gì. Việc bảo vệ không lộ địa chỉ MAC cố định là một vấn đề an toàn các hãng đang cố bảo vệ người dùng, không có lý do gì chúng ta lại tự hào với việc dùng app để lấy địa chỉ MAC cố định của một người không tham gia cài app.

Cảm ơn @phanduonghieu đã chia sẻ một lo ngại hết sức hợp lý là việc ghi nhận MAC của người khác có vi phạm gì không? Về việc này nhóm phát triển đã phân tích rất kỹ trước khi làm. Thứ nhất việc ghi nhận địa chỉ MAC sử dụng hàm có sẵn trong hệ điều hành và nó là việc hợp pháp vì đây là tính năng được hệ điều hành cho phép. Thứ hai là khi 1 thiết bị đã phát public MAC tức là cho phép các thiết bị khác sử dụng, nó giống như gặp một người họ đeo biển tên, mọi người cùng đọc thấy. Việc này hoàn toàn hợp lệ.

việc sinh các ID ngẫu nhiên này cần do bản thân máy cá nhân tự sinh chứ không cần phải được cấp.

Nhóm phát triển xin trao đổi lại là việc sinh các ID hiện nay là do máy người dùng tự sinh chứ không phải được cấp.

Một lần nữa xin cảm ơn bạn vì đóng góp ý kiến cho cộng đồng Bluezone.

phanduonghieu commented 4 years ago

Chào BkavMS17,

Cảm ơn bạn đã phản hồi.

Chỗ này có lẽ bạn đã hiểu nhầm về ý của mục 6.1 trong Whitepaper. Bluezone vẫn sinh ID cho mỗi người dùng chứ không dùng địa chỉ MAC để thay cho Bluezone ID. Ý của team phát tiển là do Bluetooth Classic quảng bá sẽ luôn gắn với 1 địa chỉ MAC cố định của điện thoại từ khi xuất xưởng. Như vậy, bản chất điện thoại đã thực hiện quảng bá ra 1 ID cố định qua Bluetooth Classic, nên việc sinh ID ngẫu nhiên không làm ẩn danh tốt hơn.

Tôi không hiểu nhầm. Ý tôi là việc các bạn nói đằng nào mỗi điện thoại cũng gắn với một unique MAC address nên dùng nhiều ID không có tác dụng là không đúng, việc lấy unique MAC address không dễ (ở chế độ non-discoverable) và không thể sử dụng nó để thay thế cho việc dùng nhiều ID. Tất cả thế giới đều sinh nhiều ID để chống việc liên kết các hoạt động của một người (linkability), ta không thể nói tôi có thể lấy unique MAC address từ tín hiệu quảng bá (chế độ discoverable) và hack để lấy unique MAC address (chế độ non-discoverable)  nên sinh nhiều ID không có tác dụng vì đằng nào tôi cũng sẽ link được hết chúng với nhau vào unique MAC address.

Điều này sai về nguyên tắc, một thành phố có một vài tên trộm giỏi không có nghĩa mọi nhà không cần làm cửa vì đằng nào nó chẳng phá được. Nếu không làm cửa thì ai ai cũng vào được tự do (có  hai điện thoại bất kỳ đặt ở hai nơi quan sát thấy 1 số hiệu là có thể liên kết được hành trình). Thiết kế cần phải tối ưu rủi ro, sinh nhiều ID thì chống được kẻ quan sát thụ động, còn chỉ 1 ID thì ngay cả kẻ quan sát thụ động (phổ biến) cũng không chống được. Ngoài ra để phương án của thế giới tương đương về độ ẩn danh như bạn nói thì phải hack mọi lúc mọi nơi đối với từng thiết bị để gắn kết tất cả các ID vào địa chỉ MAC cố định, điều này tất nhiên không khả thi và do đó khẳng định "việc sinh ID ngẫu nhiên không làm ẩn danh tốt hơn" là không đúng.

Tuy nhiên điểm này các bạn nói rằng sẽ sinh nhiều ID thì có lẽ các bạn cũng đã thấy vấn đề. Tôi không cho rằng cần phải đợi Google/Apple cập nhật và sử dụng lại hàm sinh ID của họ. Việc sinh nhiều ID có ý nghĩa ngay khi thực hiện.

Lý do chỉ dùng một ID và dùng ID ngắn có 6 ký tự (ít hơn 32 bít) để gói gọn trong 1 gói tin BLE gây ra quá nhiều vấn đề về Privacy. Cần làm như thế giới sử dụng ID 128 bít (như DP3T) và được sinh “ngẫu nhiên” liên tục (thông qua sử dụng hash function các bạn đã biết).  

Nhóm phát triển xin trao đổi lại là việc sinh các ID hiện nay là do máy người dùng tự sinh chứ không phải được cấp.

Đây có lẽ là điểm tích cực lớn nhất. Tôi đã đọc không đúng ý các bạn. Do đọc "Tại sao chúng tôi lại không sinh nhiều Bluezone ID thay vì chỉ sinh một mã" và khi có phát hiện F0 không thấy người dùng gửi thông tin lên server mà "server liên hệ với tất cả những người hệ thống CPMS gửi broadcast thông tin BLID của F0 xuống tất cả các client." nên tôi hiểu nhầm rằng rằng server đã có sẵn tập trung thông tin. Nếu server không lưu bất cứ thông tin nào của người dùng (khi họ chưa bị bệnh) thì rất tích cực. Tôi đề nghị viết cho rõ hơn là khi phát hiện bệnh, người bệnh cần phải gửi ID đã sinh trong máy của mình cho cơ quan Y tế để sau đó cơ quan y tế gửi cho backend server (hoặc nhu phương án DP3T là người bệnh gửi cho backend server thông qua mã chứng thực của cơ quan Y tế). Có lẽ nên nhấn mạnh phương án chúng tôi là Dêcntralized, là phương án thế giới đánh giá cao hơn về Privacy so với Centralized. (Update: Các bạn vẫn chưa làm rõ và khẳng định điểm này nên hệ thống có thực sự là Decentralized hay không được bàn ở comment phía dưới: https://github.com/BluezoneGlobal/documents/issues/3#issuecomment-623075755)

Cảm ơn @phanduonghieu đã chia sẻ một lo ngại hết sức hợp lý là việc ghi nhận MAC của người khác có vi phạm gì không? Về việc này nhóm phát triển đã phân tích rất kỹ trước khi làm. Thứ nhất việc ghi nhận địa chỉ MAC sử dụng hàm có sẵn trong hệ điều hành và nó là việc hợp pháp vì đây là tính năng được hệ điều hành cho phép. Thứ hai là khi 1 thiết bị đã phát public MAC tức là cho phép các thiết bị khác sử dụng, nó giống như gặp một người họ đeo biển tên, mọi người cùng đọc thấy. Việc này hoàn toàn hợp lệ.

Đây có lẽ là điểm quan trọng nhất. Trước tiên cần khằng định unique MAC address là personal data (xem chẳng hạn https://www.threegraceslegal.co.uk/blog/are-mac-addresses-personal-data)

Với personal data thì bạn không có quyền thu thập, lưu giữ và xử lý nếu không xin phép. Xem Article 6 trong GDPR (https://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm ) hoặc "Legitimate basis for processing MAC addresses and location data" trong bài này https://www.privacycompany.eu/blogpost-en/what-does-the-gdpr-say-about-wifi-tracking?fbclid=IwAR2y9DFd0XIFYedbVUWG0WcPE-e7DeK7mIEpsrUbvag4Dc1SOtcxTQF3ObI

Không thể nói cứ tín hiệu phát là tôi có quyền lưu giữ và xử lý. Mục đích phát unique MAC address là để kết nối với các thiết bị khác khi cả hai đồng ý. Không có chuyện một bên thứ ba nhìn thấy là có quyền ghi và sau đó sử dụng cho các mục đích mà người phát không biết, đây chính là một hình thức nghe lén.

Nếu bạn lấy ví dụ thì cần lấy ví dụ là khi hai người muốn nói chuyện với nhau (họ ở chế độ discoverable), họ giơ biển tên cho nhau để kết nối. Một người thứ 3 nhìn thấy, chụp lại và lưu giữ. Trường hợp khác nếu họ ở chế độ non-discoverable, tức là họ không giơ biển tên mà vẫn cố tình dùng nghiệp vụ triết xuất tên của họ và lưu giữ thì còn tệ hơn.

Không phải tôi ra đường không đeo mặt nạ là ai cũng có thể chụp hình tôi và lưu trữ thông tin vào hệ thống để sử dụng, đây là khởi đầu của các hệ thống giám sát trên diện rộng ta cần phải tránh. Chính bởi việc các thông tin có sẵn rất nhiều nên mới cần phân biệt thông tin nào là có thể thu được về mặt kỹ thuật, và thông tin nào thì được phép sử dụng. Do đó mới có việc kiểm toán code của phần mềm để xem có tuân thủ đúng thiết kế hay không, có cài những kỹ thuật nghe lén thu thập dữ liệu hay không, đặc biệt với các phần mềm quốc gia dùng trên diện rộng như ở đây. Thiết kế như hiện tại hàm chứa sự tự hào của việc nghe lén và sử dụng personal data và trái các tiêu chuẩn privacy. Một khi đã đưa ra quốc tế không thể để điều này xảy ra.

Best regards, PDH

vqhuy commented 4 years ago

Update: GS @phanduonghieu có góp ý về tấn công mô tả phía dưới, sau khi trao đổi thì tôi có sửa lại một chút theo chính kịch bản đưa ra trong whitepaper.

Một điểm bổ sung vào ý kiến của GS @phanduonghieu về việc thu thập dữ liệu địa chỉ MAC cố định của các thiết bị không cài đặt Bluezone, bên cạnh yếu tố chính sách về an toàn riêng tư như GS đã đề cập, tôi nghĩ "giải pháp" này còn dẫn đến một tấn công khác như sau.

Trong whitepaper, mục 6.2 có mô tả một kịch bản như sau:

Nguy cơ chơi xấu: nếu kẻ xấu thực hiện ghi nhận tất cả các Bluezone ID của tất cả các bệnh nhân đến khám tại 1 cơ sở y tế, ví dụ đặt 1 thiết bị thu tín hiệu BLE tại cơ sở này. Sau đó hắn sử dụng 1 thiết bị phát Bluetooth đặt tại nơi công cộng hoặc nơi làm việc của một đối thủ. Thiết bị phát này sẽ phát đi tín hiệu Bluezone giả mạo các Bluezone ID đã thu thập được trước đó.

Kẻ tấn công có thể thay vì ghi nhận Bluezone ID, sẽ ghi nhận các địa chỉ MAC cố định và phát đi các địa chỉ MAC này (xác suất thu thập được địa chỉ MAC cố định của kẻ tấn công bằng với xác suất thu thập của Bluezone, đồng nghĩa với việc Bluezone càng hiệu quả trong thu thập tiếp xúc qua ghi nhận địa chỉ MAC thì tấn công càng mạnh).

Trong whitepaper, mục 5 có viết:

  1. Với F0 không cài App: : hệ thống CPMS gửi broadcast thông tin MAC Bluetooth của F0 xuống các client.

Như vậy, nếu có 1 người từ cơ sở y tế trên (không dùng Bluezone) bị dương tính, tất cả người dùng Bluezone sẽ nhận được thông báo đã tiếp xúc với địa chỉ MAC này.

Với tấn công trên, kể cả khi dùng "giải pháp" (có rất nhiều vấn đề về an toàn riêng tư) mà các bạn nhắc tới trong whitepaper, mục 6.2 cũng sẽ không bảo vệ được người dùng. Ý tưởng chính của các bạn là sử dụng tính đối xứng: nếu hai người thực sự tiếp xúc nhau thì sẽ cùng có trong danh sách của nhau. Tuy nhiên, tấn công tôi mô tả phía trên khai thác vào việc thu thập "tùm lum" địa chỉ MAC của cả những cá nhân không dùng Bluezone. Tính đỗi xúng bị mất đi ngay cả khi hai người thực sự tiếp xúc. Ở phía người dùng Bluezone sẽ ghi nhận trong cơ sở dữ liệu các tiếp xúc này, nhưng ở phía người bệnh không dùng Bluezone thì lại không có các thông tin tiếp xúc. Việc bất đối xứng trong ghi nhận thông tin dẫn đến việc sẽ không thể kiểm tra chéo được và do vậy không chống được attack.

Bên cạnh đó, tôi cho rằng tấn công này nguy hiểm hơn hẳn replay attacks: đối với replay attacks, kẻ tấn công phải tham gia hệ thống mới thu được ID rồi sau đó phát, ở đây kẻ tấn công không cần tham gia, cứ thu hết rồi phát thả cửa. Bluezone ID theo mô tả chỉ tồn tại 2 tuần rồi xoá, nhưng các địa chỉ MAC này thì không thể, tức là nó sẽ có tác dụng mãi mãi.

Việc thu thập MAC không chỉ vi phạm tính an toàn riêng tư cá nhân như GS @phanduonghieu đã chỉ rõ ở trên, mà còn tạo ra một tấn công mà chính bản thân Bluezone muốn phòng chống.

BkavMS17 commented 4 years ago

Xin chào @phanduonghieu,

Chúng tôi đã phân tích các vấn đề bạn nêu và có phản hồi như sau:

Đây có lẽ là điểm quan trọng nhất. Trước tiên cần khằng định unique MAC address là personal data (xem chẳng hạn https://www.threegraceslegal.co.uk/blog/are-mac-addresses-personal-data)

Với personal data thì bạn không có quyền thu thập, lưu giữ và xử lý nếu không xin phép. Xem Article 6 trong GDPR (https://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm ) hoặc "Legitimate basis for processing MAC addresses and location data" trong bài này https://www.privacycompany.eu/blogpost-en/what-does-the-gdpr-say-about-wifi-tracking?fbclid=IwAR2y9DFd0XIFYedbVUWG0WcPE-e7DeK7mIEpsrUbvag4Dc1SOtcxTQF3ObI

Đầu tiên cùng phân tích article 6 của EU GDPR:

Processing shall be lawful only if and to the extent that at least one of the following applies:

(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

Theo mục (d): việc xử lý dữ liệu được phép nếu cần thiết để bảo vệ 'vital interests' của chủ thể dữ liệu hoặc người khác. Trong trường hợp của Bluezone, người lưu trữ dữ liệu có nguy cơ bị nhiễm covid-19 do tiếp xúc F0, tức là có nguy cơ đến sự sống còn của người đó nên việc lưu dữ liệu vì mục đích này được chấp nhận.

Còn theo mục (e): Việc xử lý là cần thiết để thực hiện một nhiệm vụ được thực hiện vì lợi ích công cộng hoặc trong việc thực thi quyền lực chính thức, hợp pháp. Bluezone là dự án có nhiệm vụ phục vụ lợi ích công cộng nên cũng phù hợp với điểm này.

Như vậy, việc Bluezone lưu trữ MAC address để phục vụ cho quyền lợi sống còn của người dùng và phục vụ cho lợi ích của cộng đồng là hoàn toàn phù hợp với EU GDPR.

Bạn có thể xem mã nguồn của Bluezone thì thấy, Bluezone được thiết kế để có nhiều tùy chọn và phù hợp với luật pháp của từng nước khác nhau. Mỗi nước có thể áp dụng luật tương ứng của mình

Cảm ơn @phanduonghieu đã quan tâm và đóng góp ý kiến tích cực cho Bluezone. Chia sẻ thêm với bạn là trong quá trình xây dựng Bluezone, nhóm phát triển cũng đã tìm hiểu kỹ các giải pháp của các nhóm đang triển khai trên thế giới, trong đó bao gồm 2 giải pháp là sản phẩm đã hoàn thành và được public của Singapore và sản phẩm mới ở mức concept của DP3T. Sau khi phân tích kỹ các giải pháp của thế giới, bao gồm cả sản phẩm hoàn thiện và sản phẩm concept, kết hợp với các hiểu biết về hệ thống android và iOS, nhóm thấy rằng các giải pháp này chưa lường hết được các vấn đề trong thực tế. Đồng thời vấn đề về pin cũng đang là điểm yếu của các giải pháp này, bluezone đã có những nghiên cứu để tối ưu năng lượng, chỉ sử dụng năng lượng chỉ bằng 1/2 so với các giải pháp khác (tham khảo mục 8 - whitepaper: Tối ưu năng lượng). Nhóm cũng đã liên hệ và làm việc cùng apple, google, từ đó đi đến quyết định xây dựng giải pháp như đã mô tả trong whitepaper. Theo phân tích của nhóm thì đây là giải pháp tối ưu ở thời điểm hiện tại, nhóm cũng quyết định mở mã nguồn và tài liệu để cộng đồng cùng phân tích, đóng góp và xây dựng sản phẩm. Rất mong tiếp tục nhận được sự đóng góp của mọi người.

Trân trọng,

phanduonghieu commented 4 years ago

Chào bạn,

Cảm ơn vì các trao đổi và chia sẻ để mọi vấn đề được sáng rõ hơn.

Như vậy chúng ta đã thống nhất rằng Bluezone thu thập thông tin cá nhân trên diện rộng.

Lý do Bluezone đưa ra là vì lợi ích của cá nhân bị lấy thông tin và vì lợi ích cộng đồng nên không cần hỏi.

Như vậy Bluezone cần thông báo rõ điều này cho tất cả mọi người biết. Thu thập thông tin 1 cá nhân đã cần những ly do đó, ở đây là thu thập thông tin trên diện rộng toàn dân thì rất cần sự rõ ràng công khai. Tổ chức mật mã thế giới phản đối mạnh mẽ mọi giải pháp kỹ thuật có sự giám sát trên diện rộng của các chính phủ, công ty và năm 2014 đã đưa ra một tuyên bố Copenhagen tại đây: https://www.iacr.org/misc/statement-May2014.html

IACR Statement On Mass Surveillance ("Copenhagen Resolution") The following statement was adopted unanimously by the IACR Members meeting held at Eurocrypt 2014 in Copenhagen on May 14th 2014: The membership of the IACR repudiates mass surveillance and the undermining of cryptographic solutions and standards. Population-wide surveillance threatens democracy and human dignity. We call for expediting research and deployment of effective techniques to protect personal privacy against governmental and corporate overreach.

Nếu không thay đổi, Bluezone cần thông tin rõ ràng như sau: "Vì sức khoẻ cộng đồng, phầm mềm Bluezone sẽ thu thập và sử dụng thông tin cá nhân (cụ thể là địa chỉ MAC cố định trong máy người dùng) khi cần thiết của tất cả mọi người để phục vụ việc truy vết Covid19."

Đồng thời với thông báo đó, sẽ phải rút xuống tuyên bố mà tôi cho rằng đột phá của chính phủ về Privacy. Cụ thể Bộ Trưởng Bộ TTTT tuyên bố ở đây: https://www.nhandan.com.vn/khoahoc-congnghe/item/44133602-ung-dung-bluezone-dot-pha-trong-su-dung-cong-nghe-chong-dich-covid-19.html?fbclid=IwAR3EwB0FXUb4b0wbKfDsoxixCD5Jz9AEJvPxwrEseQ8D0l6P0LsjK35hN-E "Theo Bộ trưởng, ứng dụng Bluezone là một bước tiến mới, có tính đột phá trong việc sử dụng công nghệ để phòng chống dịch. Đột phá ở chỗ, chính quyền không thu thập thông tin của người dân, các thông tin chỉ được lưu trên máy điện thoại của cá nhân. Ứng dụng chỉ ra đúng những người tiếp xúc đủ gần và đủ lâu để có thể lây nhiễm, tránh việc một người bị nhiễm thì cả làng, cả khu bị cách ly. Phần mềm này sẽ mang tính toàn cầu, sẽ được để ở dạng nguồn mở để các quốc gia được chia sẻ, các công ty, các hãng công nghệ lớn như Apple và Google sẽ cùng chung tay phát triển, và để người dân được giám sát phần mềm mình đang dùng có an toàn không."

Như vậy "Đột phá ở chỗ, chính quyền không thu thập thông tin của người dân" là không còn đúng nữa và cần rút lại. Như vậy "Phần mềm này sẽ mang tính toàn cầu" không còn đúng nữa, nó trái với sự phản đối mang tính toàn cầu được tổ chức Mật mã tuyên bố phía trên.

Ý kiến của tôi:  Để thực sự là đột phá và mang tính toàn cầu theo tuyên bố của Chính Phủ, tôi cho rằng Bluezone nên bỏ phần thu thập thông tin cá nhân này. Nếu không nó rất có khả năng sẽ là sản phẩm bị quốc tê nêu tên là "Với lý do dịch bệnh, VN đã vận dụng tới một công cụ mass surveillance". 

Ngoài ra, việc sử dụng thông tin cá nhân này - địa chỉ MAC cố định - về mặt kỹ thuật lại gây thêm một attack (do bạn Vũ Huy nêu ra phía trên) mà các bạn muốn tránh do tính bất đối xứng thông tin (người dùng ghi nhận thông tin tiếp xúc - người ngoài bluezone không ghi nhận thông tin gì, do vậy cách chống replay/relay mà các bạn tự hào dựa trên check chéo không còn ý nghĩa). 

Cuối cùng, như đã từng nói, tôi đánh giá rất cao việc Bluezone minh bạch thiết kế và code. Chính bởi sự minh bạch đó và bởi phần mềm sẽ được sử dụng trên toàn quốc, các vấn đề cần được xem xét kỹ. Tôi cũng đã rất phấn chấn với phát biểu đột phá của chính phủ về Privacy và nghĩ khi chính phủ đã có tư tưởng đột phá như vậy, chắc chắn những người làm công nghệ và thiết kế sẽ theo tinh thần đó. Do vậy kỳ vọng sản phẩm sẽ đạt đúng chuẩn đó. Ngay cả truy vết thủ công, ta có thể hỏi người bệnh về toàn bộ lịch trịch cá nhân vì lý do chống dịch, thì đó đúng là vì lợi ích cộng đồng và sự truy xuất chỉ trên cá nhân riêng lẻ. Còn ở đây là công cụ thu thập tự động khắp mọi nơi, với mọi người, trên diện rộng toàn quốc, và nó có thể là tiền đề cho những lần sử dụng tương tự về sau (với lý do vì cộng đồng), vấn đề là ở chỗ đó. 

Trân trọng, PDH.

BkavMS17 commented 4 years ago

Chào @phanduonghieu ,

Cuối cùng, như đã từng nói, tôi đánh giá rất cao việc Bluezone minh bạch thiết kế và code. Chính bởi sự minh bạch đó và bởi phần mềm sẽ được sử dụng trên toàn quốc, các vấn đề cần được xem xét kỹ. Tôi cũng đã rất phấn chấn với phát biểu đột phá của chính phủ về Privacy và nghĩ khi chính phủ đã có tư tưởng đột phá như vậy, chắc chắn những người làm công nghệ và thiết kế sẽ theo tinh thần đó. Do vậy kỳ vọng sản phẩm sẽ đạt đúng chuẩn đó. Ngay cả truy vết thủ công, ta có thể hỏi người bệnh về toàn bộ lịch trịch cá nhân vì lý do chống dịch, thì đó đúng là vì lợi ích cộng đồng và sự truy xuất chỉ trên cá nhân riêng lẻ. Còn ở đây là công cụ thu thập tự động khắp mọi nơi, với mọi người, trên diện rộng toàn quốc, và nó có thể là tiền đề cho những lần sử dụng tương tự về sau (với lý do vì cộng đồng), vấn đề là ở chỗ đó.

Xin làm rõ là Bluezone hiện nay đang hoạt động đúng như kỳ vọng của bạn. Bluezone hoạt động theo nguyên tắc decentralized, có nghĩa là dữ liệu chỉ ghi nhận trên từng máy cá nhân đơn lẻ, không chuyển lên hệ thống (tham khảo whitepaper, mục 3.2). Vì dữ liệu chỉ lưu trữ trên máy cá nhân và ghi nhận đơn lẻ theo từng máy, nên không có sự thu nhận, giám sát trên diện rộng.

Bạn có thể xem kỹ hơn mục 3.1 trong whitepaper để hiểu về nguyên tắc decentralized của Bluezone như sau: Khi có một ca nhiễm SARS-CoV-2 mới, cơ quan y tế nhập dữ liệu F0 này lên hệ thống. Hệ thống sau đó gửi dữ liệu F0 đến các smartphone khác cài ứng dụng Bluezone. Lịch sử tiếp xúc với F0 trong 14 ngày trước đó sẽ được phân tích, đối chiếu và nếu trùng khớp, ứng dụng Bluezone sẽ cảnh báo cho người dùng có nguy cơ lây nhiễm, đồng thời hướng dẫn họ liên hệ với cơ quan Y tế để nhận trợ giúp.

Mục 6.2 cũng nêu rõ: Giải pháp chúng tôi đưa ra như sau: cho phép khi 1 Bluezoner giả định có phát hiện tiếp xúc F0 (nhận được thông tin qua broadcast), Bluezoner này sẽ có tùy chọn xác minh F0 mình đã tiếp xúc có đúng là F0 thật hay không, bằng cách gửi lịch sử tiếp xúc F0 của mình lên hệ thống để so sánh với lịch sử tiếp xúc của F0 đã được cơ quan Y tế cập nhật. Nếu không có sự tương đồng, Bluezoner không phải là F1.

Như vậy, hiện nay dữ liệu đang hoàn toàn chỉ ghi nhận đơn lẻ trên máy người dùng theo nguyên tắc decentralized và chính quyền không thu thập các thông tin này. Đúng như đề xuất của bạn.

Trân trọng,

phanduonghieu commented 4 years ago

Tôi không biết bạn BkavMS17 dưới này có phải là bạn BkavMS17 trên kia. Tất cả các giải thích kỹ thuật của bạn tôi đã nắm rõ. Bạn trên kia đã có những trao đổi rất tích cực, và nói lý do thu thập thông tin cá nhân là để phục vụ lợi ích sống còn của người dùng và phục vụ cho lợi ích của cộng đồng. Bạn dưới này thì phủ nhận tất cả.   Bluezone là giải pháp của chính quyền, trong giải pháp đó cho phép mỗi máy thu thập thông tin của nhũng người không liên quan và không cần hỏi họ. Nếu chính quyền không liên quan thì làm sao mỗi máy cá nhân có quyền tự ý thu thập thông tin người khác mà không xin phép như vậy? Nếu chính quyền bảo lãnh cho điều đó thì cần tuyên bố công khai lý do. 

Việc phát triển ứng dụng trên diện rộng gây rất nhiều lo ngại về việc nó có thể trở thành công cụ giám sát trên diện rộng (dù tự bản thân ứng dụng chưa phải là công cụ giám sát). Đó là lý do tại sao ở các nước đều có những tranh luận công khai chuyện này, và đã có những kiến nghị của cộng đồng khoa học tại Pháp, tại Anh cảnh báo chính phủ về nguy cơ trở thành công cụ giám sát trên diện rộng. Ở tất cả nơi đó, giải pháp của họ còn chưa có nơi nào mà mỗi máy cài ứng dụng lại tự ý thu thập thông tin của những người không tham gia ứng dụng. 

Trân trọng, PDH

BkavMS17 commented 4 years ago

Chào @phanduonghieu

Tôi không biết bạn BkavMS17 dưới này có phải là bạn BkavMS17 trên kia. Tất cả các giải thích kỹ thuật của bạn tôi đã nắm rõ. Bạn trên kia đã có những trao đổi rất tích cực, và nói lý do thu thập thông tin cá nhân là để phục vụ lợi ích sống còn của người dùng và phục vụ cho lợi ích của cộng đồng. Bạn dưới này thì phủ nhận tất cả.

Vẫn là mình đây, và mình không phủ nhận những gì mình đã trao đổi. Bạn vẫn chưa hiểu phần giải thích của mình thì phải. Như ở bài trên mình cũng đã giải thích việc thu thập địa chỉ MAC để bảo vệ chính lợi ích sống còn của người dùng và bảo vệ cộng đồng. Trong trường hợp 1 trong những người đã tiếp xúc là F0 thì dữ liệu MAC mà máy của người dùng thu thập được sẽ giúp người dùng biết mình đã bị phơi nhiễm và cần các biện pháp để đảm bảo an toàn sức khỏe cho bản thân cũng như cho cộng đồng.

phanduonghieu commented 4 years ago

Ồ, lợi ích của việc sử dụng MAC cố định này sao mình không hiểu, vấn đề là phải thông báo công khai, tường minh lý do cho việc tự ý thu thập MAC cố định (thông tin cá nhân) của người không tham gia Bluezone. Nói về kỹ thuật, vấn đề phức tạp hơn là việc sử dụng MAC cố định gây ra tấn công bạn @vqhuy mô tả phía trên kia mà có lẽ bạn chưa nắm được, xin lỗi nếu đánh giá sai vì chưa thấy bạn phản hồi. Để mình giải thích lại: 

Ý tưởng chống tấn công giả định Phần 6.2 (cuối trang 7) của bạn là kiểm tra chéo: khi A thấy trong contact của mình có ID nhiễm bệnh của B thì nhờ cơ quan Y tế kiểm tra xem trong danh sách contact của B có ID của A hay không, nếu có mới khẳng định A là F1. Sự kiểm tra chéo này chỉ có thể thực hiện khi A và B cùng tham gia Bluezone. Nếu B không tham gia Bluezone và trước đó kẻ tấn công lấy MAC cố định của B phát tán, gửi cho A thì trong danh sách của A có MAC cố định của B. Khi B nhiễm bệnh thì không có cách nào kiểm tra chéo được để biết A có là F1 hay không vì B không tham gia Bluezone nên không có danh sách contact để đối chiếu.  Việc bất đối xứng này làm các bạn không thể giải quyết vấn đề chống replay/replay attack mà các phương án của Vaudenay và Pietrzak đề nghị vì họ đều cần cả hai cùng tham gia app: Giải pháp của Vaudenay: https://eprint.iacr.org/2020/399.pdf Giải pháo của Pietrzak: https://eprint.iacr.org/2020/418.pdf Cũng về kỹ thuật, việc thường xuyên nghe địa chỉ MAC cố định cũng đi ngược lại với cố gắng tiết kiệm pin của các bạn vì đây là cố nghe tín hiệu Bluetooth Classic và tốn hơn nhiều so với nghe BLE. Trân trọng,  PDH

hadv commented 4 years ago

Ngoài ra, @BkavMS17 xác nhận giúp mình là trong trường hơp một cá nhân có tiếp xúc với F0 thì cả 2 lựa chọn sau ít nhiều đều gửi dữ liệu về lịch sử tiếp xúc của F1 lên server đúng không?

Nếu đúng thì đâu phải dữ liệu chỉ lưu trữ ở máy cá nhân. Nên các bạn cũng cần thông tin rõ ràng và công khai cho cộng đồng về việc thu thập dữ liệu người dùng khi có phát hiện tiếp xúc với F0.

image

phanduonghieu commented 4 years ago

Thảo luận kỹ hơn về Decentralized và các vấn đề kỹ thuật chưa được trả lời về MAC cố định.

Một hệ thống muốn đạt Decentralized thì phải thoả mãn điều kiện sau: server chỉ lưu duy nhất những ID của F0. Một cách thường xuyên (hoặc khi người dùng yêu cầu), server sẽ broadcast các thông tin này để người dùng tự kiểm tra trên máy của mình xem có là F1 hay không.

Câu hỏi của bạn @hadv đặt ra rất đúng, nếu server còn lưu những dữ liệu khác ngoài những ID của các F0 thì nó sẽ mất tính decentralized và không thể khẳng định “dữ liệu chỉ lưu trữ trên máy cá nhân”.

Một điểm không rõ ràng nữa trong whitepaper là “Khi có thông tin chính thức về F0 từ nguồn dữ liệu của Cơ quan Y Tế có thẩm quyền, Quản trị hệ thống sẽ thực hiện việc cập nhật thông tin trên chức năng Nhập thông tin F0 của hệ thống Backend CPMS.”
Cụ thể các bạn có thể cho biết Quản trị hệ thống sẽ lưu những thông tin gì từ máy của F0? Đây là vấn đề quan trọng mà tài liệu chưa nói rõ và đặc biệt không có open source phần này để kiểm tra. Vậy sẽ có nhiều trường hợp xảy ra:

  1. Sẽ chỉ lưu ID của F0. Nhưng nếu như vậy thì trong Hình 1 “Cách thức hoạt động của Bluzeone” sẽ không thể có chức năng “Ứng dụng có thể giúp cảnh báo cho người thuộc nhóm F2”.
  2. Sẽ lưu ID của F0 và tất cả các ID của F1 trong máy F0 (tức là các ID mà F0 đã tiếp xúc và được ghi nhận ở trong máy F0). Với hình thức này, có thể có chức năng “Ứng dụng có thể giúp cảnh báo cho người thuộc nhóm F2”. Tuy nhiên hệ thống sẽ không còn là Decentralized theo điều kiện kể trên. Nó có thể coi nằm ở khoảng giữa Decentralized và Centralized.
  3. Sẽ lưu ID của F0 và tất cả các ID và MAC cố định của F1 trong máy F0 (tức là các ID mà F0 đã tiếp xúc được ghi nhận ở trong máy F0 và cả các địa chỉ MAC cố định của những người không tham gia Bluezone đã ghi nhận trong máy F0). Với hình thức này, có thể có chức năng “Ứng dụng có thể giúp cảnh báo cho người thuộc nhóm F2”. Tuy nhiên hệ thống sẽ không những không còn là Decentralized mà còn có đặc điểm yếu hơn một hệ thống Centralized thông thường (chỉ lưu, quản lý các ID của những người tham gia cài phần mềm) khi lưu cả thông tin cá nhân (MAC cố định) của những người không tham gia Bluezone.

Liên quan đến các vấn đề kỹ thuật, đề nghị @BkavMS17 thông tin rõ những câu hỏi chưa được trả lời trong mục này, liên quan đến việc thu và sử dụng địa chỉ MAC cố định của cả những người không tham gia Bluezone: Q1. Trả lời vấn đề của bạn @thaidn nêu ra: hiện tại hệ thống thu địa chỉ MAC cố định của những người không tham gia và ghi vào cả ở bộ nhớ ngoài ứng dụng (extenal storage) và như vậy, các app khác cũng có thể đọc được. Điều này gây nguy hiểm ở chỗ vừa thu thập thông tin cá nhân của người không tham gia, vừa không bảo vệ nó khỏi những ứng dụng khác trong điện thoại. Chỉ cần 1 ứng dụng trò chơi không an toàn là toàn bộ dữ liệu cá nhân này sẽ bị mất vào tay kẻ xấu. Q2. Trả lời câu hỏi về attack của bạn @vqhuy mà tôi đã giải thích thêm trong comment phía trên. Nếu không giải quyết được attack này thì trong mục 6.2 các bạn phải thay thế câu nói là các nhóm trên thế giới chưa giải quyết được loại relay/replay attack mà các bạn giải quyết được. Thực tế tình huống sẽ là ngược lại, thế giới đã có phương án giải quyết được mô tả trong bài báo của Vaudenay và Pietrzak tôi nêu phía trên, còn với hệ thống Bluezone thì chưa có cách giải quyết vì không áp dụng được phương án của Vaudenay và Pietrzak khi hai phương án này đều đòi hỏi sự tiếp xúc phải là giữa hai người cùng dùng app (có tính đối xứng) còn Bluezone thu thập cả MAC cố định của người không tham gia thì không luôn có tính chất đối xứng này. Q3. Về vấn đề hệ thống của các bạn có thực sự Decentralized hay không: cần trả lời các câu hỏi của @hadv và của tôi phía trên.

Trân trọng, PDH

phanduonghieu commented 4 years ago

Trong khi các bạn đang suy nghĩ để trả lời những vấn đề trên, tôi bổ sung thêm một câu hỏi nữa:

Q4. Các bạn đã có phương án bảo vệ người cài Bluezone khi đi ra nước ngoài chưa? Một người cài Bluezone khi đi ra nước ngoài, chẳng hạn châu Âu, nếu không gỡ Bluezone thì nghiễm nhiên trở thành một người mang thiết bị nghe lén thông tin cá nhân ( như đã thống nhất, MAC cố định là thông tin cá nhân, thu thập mà không được sự đồng ý là nghe lén). Luật các nước phạt rất nặng chuyện này. Nếu không thông tin đầy đủ sẽ đặt người sử dụng vào nguy cơ bị kiện theo luật nước ngoài. Nhất là khi quảng bá là giải pháp toàn cầu sẽ làm người dùng chủ quan, khi ra nước ngoài tiếp tục sử dụng. Hãy xét tình huống như sau: một phái đoàn ngoại giao của chính phủ nước ta sang thăm nước bạn và họp kín, nếu các thành viên trong phái đoàn cài Bluezone thì rất có thể phía bạn sẽ phát hiện và lên án chúng ta là nghe lén ở mức quốc gia. Các bạn xử lý trường hợp này thế nào? Đây là ứng dụng mang tính quốc gia (được chính phủ yêu cầu thực hiện và bảo lãnh lý do đặc biệt để có thể thu thập thông tin cá nhân không cần hỏi) nên những vấn đề này là rất quan trọng (khác với việc một công ty không tên tuổi tự ý phát hành một app trò chơi không an toàn). Do vậy khi bị nước ngoài kiện thì chính phủ không thể nói là không biết và không liên quan.

tuanta commented 4 years ago

Cụ thể các bạn có thể cho biết Quản trị hệ thống sẽ lưu những thông tin gì từ máy của F0? Đây là vấn đề quan trọng mà tài liệu chưa nói rõ và đặc biệt không có open source phần này để kiểm tra. Vậy sẽ có nhiều trường hợp xảy ra:

+1 với GS @phanduonghieu, việc này rất quan trọng.

Theo tôi, nhóm phát triển Blluezone cần phải open source cả phần back-end này, theo đúng tinh thần mà của BT Hùng & dự án đã tuyên bố. Cụ thể, tôi đề nghị open source phần back-end theo giấy phép AGPL v3 để đảm bảo chắc chắn code chạy trên back-end Bluezone chính là code được open source.

jernst commented 4 years ago

This is a fascinating discussion (which I am only following with Google Translate ... hope I'm not misunderstanding too many things). I want to commend the development team for engaging in this discussion. This is great!

But some serious issues were raised. Important open questions remain. Two weeks have passed. What are your plans to address these questions?

thaidn commented 4 years ago

I just reverse engineered the latest Android version and AFACIT Bluezone has stopped collecting Bluetooth Classic MAC addresses.

The scanning and collecting code still exists, but it is gated by a global, non-configurable option that currently is set to false [1].

@phanduonghieu I think we can close this discussion for now.

[1] https://github.com/BluezoneGlobal/react-native-bluetooth-scan/blob/master/lib/android/src/main/java/com/scan/AppConstants.java#L34

phanduonghieu commented 4 years ago

Cục Tin học hoá có trao đổi và khẳng định với tôi về sự dừng thu thập thông tin MAC cố định. Trong phiên bản mới nhất bạn @thaidn đã check và tái khẳng định điều này là chính xác. Vậy tôi close issue này tại đây và cảm ơn sự đóng góp trao đổi của các bạn tham gia.

Meigyoku-Thmn commented 4 years ago

Vậy là bên "nhà đài" chỉ im lặng rồi âm thầm sửa lỗi hả, chả có minh bạch gì hết trơn. Câu hỏi về việc làm thế nào để trích xuất dữ liệu F0 còn chưa được giải đáp.

khanguy00 commented 4 years ago

Vậy là bên "nhà đài" chỉ im lặng rồi âm thầm sửa lỗi hả, chả có minh bạch gì hết trơn.

so typical! haha

linh-ebisolvn commented 4 years ago

cho mình hỏi là nếu bluezone ID thay đổi liên tục thì làm sao các máy khác check đc là ID có trùng với ID F0 đã lưu trong db dưới máy của mình hay ko (giả dụ đã cho phép kéo data từ server về sau khi bộ y tế đã nhập thông tin F0)

Meigyoku-Thmn commented 4 years ago

cho mình hỏi là nếu bluezone ID thay đổi liên tục thì làm sao các máy khác check đc là ID có trùng với ID F0 đã lưu trong db dưới máy của mình hay ko (giả dụ đã cho phép kéo data từ server về sau khi bộ y tế đã nhập thông tin F0)

Tôi cho rằng ứng dụng này phải liên tục sync với server để server có được list gặp gỡ của mobile, list gặp gỡ thì kiểu là đã tiếp xúc với các ID nào. Mỗi list thì gắn liền với một số điện thoại nhất định. Khi bộ y tế phát hiện F0, họ sẽ dùng số đt để tìm list đó trên server và đánh dấu là F0. Sau đó server sẽ sync ngược xuống các điện thoại khác để so khớp. Nếu đã từng tiếp xúc với F0 thì các điện thoại kia sẽ khớp ít nhất là một ID nào đó của F0. Họ trở thành F1. Còn cụ thể tiếp xúc với ai thì không biết được (vì ID ngẫu nhiên liêu tục, người biết chính xác nhất thì chỉ có "nhà đài"). Tính ra chúng ta cũng chẳng cần biết source code của server làm gì, chỉ cần source code phiên bản mới nhất của client là đủ. Có thể nói rằng giải pháp này có một nửa là centralized, một nửa là decentralized.

khanguy00 commented 4 years ago

cho mình hỏi là nếu bluezone ID thay đổi liên tục thì làm sao các máy khác check đc là ID có trùng với ID F0 đã lưu trong db dưới máy của mình hay ko (giả dụ đã cho phép kéo data từ server về sau khi bộ y tế đã nhập thông tin F0)

Tôi nói theo ý tưởng của app tracking của Singapore và tôi nghĩ áp dụng được với Bluezone:

Còn điều gì thắc mắc không các bạn?

Ở đây không cần sync số điện thoại, cũng không cần gửi lên server gì hết nhé. Chỉ trừ trường hợp được bộ y tế chuẩn thuận mà thôi, mà trường hợp này nếu đúng là phải có bước authorization đàng hoàng.

khanguy00 commented 4 years ago

Nói thêm, tại sao việc F0 gửi danh sách generated ID lên server lại cần chuẩn thuận từ phía y tế?

Mục đích là tránh bị broadcast sai.

Giả dụ F0 không có bị gì hết, nhưng vì "thích" nên gửi danh sách lên server, khiến server tiếp tục broadcast đi và F1 bị nhận false alarm.

Cách người ta tránh việc này là:

Meigyoku-Thmn commented 4 years ago

@khanguy00 có vẻ hợp lý đó bác ạ, nhưng mà sao mình không nhìn thấy nút gửi danh sách ID ở đâu trong app cả, chẳng lẽ tính năng ẩn và chỉ hiện ra khi mình bị Covid-19?

khanguy00 commented 4 years ago

@Meigyoku-Thmn again, tôi chỉ nói về lý thuyết, tôi hoàn toàn không nằm trong đội phát triển Bluezone, và tôi cũng không sử dụng app này.

Rất có thể Bluezone dùng cách khác, cũng có thể dùng theo cách mà bạn đề cập. Nếu thế thì có vẻ hơi dở...

linh-ebisolvn commented 4 years ago

em nghĩ chỉ khi nào bị xác định là F0, BYT sẽ "bắt buộc" ng đó phải gửi list ID của mình lên sv. còn câu hỏi của bạn bên trên mình nghĩ là ko khả thi, vì máy client k gửi gì lên sv hết thì sao sv biết đc đó là tính năng nào ẩn mà báo cho máy client để kích hoạt hiện ra nút gửi ds lên sv?

Meigyoku-Thmn commented 4 years ago

em nghĩ chỉ khi nào bị xác định là F0, BYT sẽ "bắt buộc" ng đó phải gửi list ID của mình lên sv. còn câu hỏi của bạn bên trên mình nghĩ là ko khả thi, vì máy client k gửi gì lên sv hết thì sao sv biết đc đó là tính năng nào ẩn mà báo cho máy client để kích hoạt hiện ra nút gửi ds lên sv?

Giờ mã nguồn trên github đây còn chưa phải là mới nhất thì chúng ta chỉ có thể đoán thôi, như 2 scenario khả dĩ của mình với của bạn khanguy00.

khanguy00 commented 4 years ago

vì máy client k gửi gì lên sv hết thì sao sv biết đc đó là tính năng nào ẩn mà báo cho máy client để kích hoạt hiện ra nút gửi ds lên sv?

Ai đó cần kiểm tra lại cách vận hành của app Bluezone, rồi mới khẳng định được. Tôi là người chỉ nói lý thuyết thôi...

Tiếp tục nói lý thuyết, theo đó nhận định trên của bạn @linh-ebisolvn có thể cần suy nghĩ lại, ở 2 trường hợp sau:

Rất có thể còn nhiều cách khác, nhưng nếu không kiểm tra kỹ source code của app thì đoán hoài cũng chẳng ra...

Tuy nhiên, rất có thể họ chỉ làm như bạn nói là gửi hết lên server, lúc đó thì app Bluezone này quả là nơi thu thập dữ liệu người dùng chứ không đơn thuần là app tracking như các nước khác trên thế giới. Khi đó, câu hỏi về độ an toàn và tính riêng tư của người dùng là một dấu hỏi siêu siêu lớn.

khanguy00 commented 4 years ago

Anyway, chuyện này dường như liên quan đến #1.

thaidn commented 4 years ago

Chỗ để F0 gửi dữ liệu lên nằm ở màn hình "Giới thiệu", trên đó có một nút "Nhập mã xác thực" màu xanh. Tôi đoán là khi một người đã được xác nhận là F0 thì cơ quan y tế sẽ gửi cho họ (qua SMS hay nói trực tiếp) một mã xác thực để họ nhập vô màn hình này.

Dữ liệu mà F0 sẽ upload lên bao gồm không chỉ ID do F0 tạo ra, mà còn cả những ID mà F0 đã thấy, tức là một phần của social graph của F0.

Tôi test trên Android, phiên bản 2.0.3. Hiện giờ đã có phiên bản 2.0.4, nhưng tôi chưa có thời gian coi. Team phát triển ra phiên bản mới liên tục nên tôi thật sự không có thời gian RE hết lần này đến lần khác. Trong khi mã nguồn thì vẫn chưa được cập nhật.

tuanta commented 4 years ago

Tôi test trên Android, phiên bản 2.0.3. Hiện giờ đã có phiên bản 2.0.4, nhưng tôi chưa có thời gian coi. Team phát triển ra phiên bản mới liên tục nên tôi thật sự không có thời gian RE hết lần này đến lần khác. Trong khi mã nguồn thì vẫn chưa được cập nhật.

Đây là vấn đề đã góp ý cho team phát triển rất nhiều lần, nhưng chưa thấy thay đổi. Nếu Team phát triển không làm việc trực tiếp với mã nguồn trên kho GitHub này & public đúng mã nguồn của bản phát hành thì khó có gì đảm bảo phiên bản trên Google Play / App Store đã được peer-review. Ngồi mà soi lại từng lần thế này thì toi :(

Meigyoku-Thmn commented 4 years ago

À đúng là có cái nút nhập mã xác thực trong phần giới thiệu thật, không biết sao lúc trước tôi bỏ qua mất phần này. Như vậy có lẽ scenario là theo đúng như bạn khanguy00 nói.

khanguy00 commented 4 years ago

Dữ liệu mà F0 sẽ upload lên bao gồm không chỉ ID do F0 tạo ra, mà còn cả những ID mà F0 đã thấy, tức là một phần của social graph của F0.

Ồ, thế thì cũng đáng quan ngại thật!

Tôi thử nghĩ lý do tại sao Bluezone lại cần social graph? Liệu nó có liên quan đến chuyện truy vết bằng công an và dân địa phương không?

Tức là giả dụ như phát hiện F0, và vì biết được một phần social graph của F0, chính quyền có thể phát hiện ra khu vực mà F0 đã đi lại, và các F1 khả dĩ ở đâu, từ đó sẽ phong tỏa luôn một khu vực rộng lớn hơn. Cách này tuy hơi tàn nhẫn, nhưng có vẻ nó phản ánh đúng với cách thức mà người dân và chính quyền tại VN đang làm, nên có lẽ được chấp nhận dễ dàng.

Một lợi ích nữa là việc xác định social graph cũng sẽ giúp phát hiện F1 thậm chí F1 còn không cài app Bluezone, tất cả là vì social graph của F0, mà F0 là ai đã được xác định danh tính rõ ràng rồi...

tuanta commented 4 years ago

Dữ liệu mà F0 sẽ upload lên bao gồm không chỉ ID do F0 tạo ra, mà còn cả những ID mà F0 đã thấy, tức là một phần của social graph của F0.

Ồ, thế thì cũng đáng quan ngại thật!

Tôi thử nghĩ lý do tại sao Bluezone lại cần social graph? Liệu nó có liên quan đến chuyện truy vết bằng công an và dân địa phương không?

Tức là giả dụ như phát hiện F0, và vì biết được một phần social graph của F0, chính quyền có thể phát hiện ra khu vực mà F0 đã đi lại, và các F1 khả dĩ ở đâu, từ đó sẽ phong tỏa luôn một khu vực rộng lớn hơn. Cách này tuy hơi tàn nhẫn, nhưng có vẻ nó phản ánh đúng với cách thức mà người dân và chính quyền tại VN đang làm, nên có lẽ được chấp nhận dễ dàng.

Một lợi ích nữa là việc xác định social graph cũng sẽ giúp phát hiện F1 thậm chí F1 còn không cài app Bluezone, tất cả là vì social graph của F0, mà F0 là ai đã được xác định danh tính rõ ràng rồi...

Tôi không nghĩ là @thaidn đang dùng từ "social graph" theo nghĩa này, mà đơn giản chỉ định nói về BluezoneID lưu trong máy F0. Chờ Thái confirm là chính xác nhất.

khanguy00 commented 4 years ago

@tuanta Tôi cũng biết là đang nói về Bluezone ID. Cái tôi thắc mắc là liệu phía bluezone có thể truy ngược lại được ko?

Nếu hoàn toàn không có cách nào truy ngược lại, thì chúng ta có thể an tâm về chuyện bị upload cả social graph của F0.

Nhưng nếu có cách truy ngược lại, thì đó sẽ là một điểm vi phạm quyền riêng tư nghiêm trọng.

Tôi chỉ đặt giả thiết, chứ không hẳn là khẳng định một luận điểm.

tuanta commented 4 years ago

@tuanta Tôi cũng biết là đang nói về Bluezone ID. Cái tôi thắc mắc là liệu phía bluezone có thể truy ngược lại được ko?

Nếu hoàn toàn không có cách nào truy ngược lại, thì chúng ta có thể an tâm về chuyện bị upload cả social graph của F0. từ đ Nhưng nếu có cách truy ngược lại, thì đó sẽ là một điểm vi phạm quyền riêng tư nghiêm trọng.

Tôi chỉ đặt giả thiết, chứ không hẳn là khẳng định một luận điểm.

@khanguy00 : chính issue này mở ra để complain về vấn đề "truy ngược" bạn đang quan tâm đây. Bạn đọc từ các comment đầu tiên xem có giải quyết được băn khoăn của bản thân chưa?

thaidn commented 4 years ago

Nhưng nếu có cách truy ngược lại, thì đó sẽ là một điểm vi phạm quyền riêng tư nghiêm trọng.

Tôi không hiểu lắm ý bạn truy ngược ở đây là như thế nào? Bạn có thể giải thích rõ thêm được không?

Hôm nay tôi đã RE xong phần lớn app (cảm ơn Uncle Sundar đã tài trợ chương trình).

Tôi sẽ viết chi tiết sau, nhưng tóm tắt lại vầy:

khanguy00 commented 4 years ago

Tôi chỉ nói chung chung thôi... Truy ngược ở đây là chuyện suy từ generated ID sang người thật. Thông thường có 2 cách truy ngược, một là do ID dễ đoán và dễ truy ngược lại, hai là do dữ liệu được lưu trong database.

Cảm ơn anh @thaidn đã cung cấp thêm thông tin, giờ thì tôi nghĩ ra một kịch bản cho việc truy ngược từ ID sang người thật:

  1. Khi F0 bị xác định là nhiễm bệnh, toàn bộ rootID và dailyID của F0 cùng với các daily ID của những người có tiếp xúc với F0 (tạm gọi là daily contacted IDs của F0) được gửi lên server.
  2. Sau khi server broadcast IDs của F0, tiếp tục thì toàn bộ root ID và daily ID và daily contacted ID của F1 đều được gửi lên server.
  3. Server giờ đã có contacted ID của F0 và có thể matching với daily ID của F1 để tạo một connect giữa F0 và F1 trên cái graph chung.
  4. Server tiếp tục broadcast IDs của F1, nhưng lần này không để bluezone app thông báo người dùng (để không ai biết), và như vậy server tiếp tục lấy được toàn bộ dữ liệu của F2, rồi lặp lại bước 3 cho F1-F2.
  5. Sau khi lặp đi lặp lại bước 4, server đã có toàn bộ dữ liệu social graph của tất cả user xài app.
  6. Trên graph này, có node có số điện thoại có node không có. Matching với một số dữ liệu quản lý khác của chính quyền, công an và hộ tịch, có thể biết chính xác người đó là ai, ở đâu, nguyên quán là gì, có họ hàng bà con với ai.
  7. Các node còn thiếu số điện thoại, có thể được kiểm tra chéo bởi hệ thống công an vốn đi tới tận mới làng xã. Tuy mất thời gian nhưng hoàn toàn có thể xác định được, nếu đối tượng đang muốn kiểm tra thuộc diện "đặc biệt cần theo dõi".

Tất nhiên, đây chỉ là lý thuyết, nhưng hoàn toàn có khả năng xảy ra rằng chính dữ liệu của bluezone là một cơ sở quan trọng xác định social graph của toàn xã hội.

Việc loại bỏ khả năng này cũng rất đơn giản: không bao giờ gửi root ID và daily ID của F0, mà chỉ là contacted ID của F0 mà thôi. Chỉ có cách này mới khiến server khó có thể matching được ai thật sự có tiếp xúc với ai, và không thể tạo social graph của toàn xã hội được.

(Tôi đã từng hỏi anh @thaidn trên blog của anh ấy về chuyện nên gửi daily ID hay contacted ID, và có vẻ gửi contacted ID thì tối ưu hơn.)

thaidn commented 4 years ago

Tôi chỉ nói chung chung thôi... Truy ngược ở đây là chuyện suy từ generated ID sang người thật. Thông thường có 2 cách truy ngược, một là do ID dễ đoán và dễ truy ngược lại, hai là do dữ liệu được lưu trong database.

Àh tôi đã hiểu ý anh. Nếu người dùng đăng ký số điện thoại thì việc truy ra với F0 khá dễ dàng. Với F1 thì máy chủ cũng chỉ cần gửi lệnh xuống máy của người dùng để hốt dữ liệu về và từ dữ liệu đó sẽ biết được người đó là ai, nếu họ có đăng ký số điện thoại. Tôi nghĩ đây là giả thuyết mà anh nói bên dưới, đúng không? Nếu vậy thì tôi xác nhận là chuyện này hoàn toàn có thể xảy ra với cách làm hiện tại của Bluezone.

Việc loại bỏ khả năng này cũng rất đơn giản: không bao giờ gửi root ID và daily ID của F0, mà chỉ là contacted ID của F0 mà thôi. Chỉ có cách này mới khiến server khó có thể matching được ai thật sự có tiếp xúc với ai, và không thể tạo social graph của toàn xã hội được.

Máy chủ Bluezone muốn có dữ liệu để làm contract tracing cho dễ và hiệu quả. Tôi nghĩ đây là một mong muốn có thể chấp nhận được, với điều kiện họ phải minh bạch về dữ liệu và thiết kế trên máy chủ.

thaidn commented 4 years ago

Tôi mới đưa lên hướng dẫn cách reproduce quan sát của tôi ở https://github.com/BluezoneGlobal/documents/issues/3#issuecomment-670312568

https://github.com/thaidn/bluezone

khanguy00 commented 4 years ago

Máy chủ Bluezone muốn có dữ liệu để làm contract tracing cho dễ và hiệu quả. Tôi nghĩ đây là một mong muốn có thể chấp nhận được, với điều kiện họ phải minh bạch về dữ liệu và thiết kế trên máy chủ.

Tôi thì cho rằng mong muốn này vượt quá mức độ cần thiết của một app contact tracking (cũng có thể tôi sai). Nhưng mà đó là quan điểm cá nhân, không quan trọng lắm.

Dù sao thì cũng nên đưa cảnh báo này trong document hoặc phần mô tả của app trên store, đại khái: Bluezone có thu thập lịch sử tiếp xúc và đưa lên server, tuy nhiên sẽ không và không bao giờ sử dụng nó cho mục đích khác hoặc chuyển giao cho bất cứ bên nào khác. (Đồng thời cũng nên bỏ đi những ý như "dữ liệu của người dùng chỉ được lưu trong máy của họ")