Blog FOSS by Lê Trung Nghĩa

https://letrungnghia.mangvn.org

TPP đã kết thúc cuộc chiến mật mã? Hầu như không.

Has the TPP Ended the Crypto Wars? Hardly.

November 18, 2015 | By Jeremy Malcolm

Theo: https://www.eff.org/deeplinks/2015/11/has-tpp-ended-crypto-wars

Bài được đưa lên Internet ngày: 18/11/2015

 

Xem thêm: TPP, ACTA, bằng sáng chế phần mềm và hơn thế nữa;

 

Đại diện Thương mại Mỹ - USTR sợ cộng đồng công nghệ của các thường dân, và đúng như thế. Những người sử dụng Internet là cộng đồng đã giết chết SOPA và PIPA tại Quốc hội MỹACTA ở Nghị viện châu Âu. USTR đúng phải sợ điều y hệt có thể xảy ra với hiệp định Đối tác Xuyên Thái bình dương - TPP (Trans-Pacific Partnership agreement).

 

Điều đó giải thích vì sao họ đã cố gắng như vậy để trình bày TPP như là thân thiện với Internet và những người sử dụng công nghệ và đã đưa vào một ít các điều khoản trong hiệp định mà họ có thể chỉ tới để chứng minh cho tuyên bố này. Chúng tôi đã đề cập tới (và đã giải mã) vài trong số đó trước rồi - lưu ý tới các quy tắc dòng chảy tự do thông tin, phổ biến cho cả TISATPP - nhưng có những điều khác đáng bình luận.

 

Dưới đầu đề “TPP làm thế nào bảo vệ được Internet và đảm bảo được sự Tự do Số”, USTR nêu trên website của nó rằng TPP “đảm bảo rằng các công ty và các cá nhân có khả năng sử dụng các công cụ an ninh không gian mạng và mã hóa mà họ thấy phù hợp, không có các hạn chế độc đoán mà có thể bóp nghẹt tự do ngôn luận”. Điều này tham chiếu tới điều khoản tù mù trước đây được ẩn dấu trong Phụ lục 8-B của chương các Rào cản Kỹ thuật đối với Thương mại [PDF] của TPP, nó nêu:

 

Với lưu ý về một sản phẩm sử dụng mật mã và được thiết kế cho các ứng dụng thương mại, không Bên nào có thể áp đặt hoặc duy trì một quy định kỹ thuật hoặc thủ tục đánh giá tuân thủ mà đòi hỏi nhà sản xuất hoặc nhà cung cấp sản phẩm, như một điều kiện sản xuất, bán hàng, phân phối, nhập khẩu hoặc sử dụng sản phẩm đó, để:

 

A. chuyển giao hoặc cung cấp sự truy cập tới công nghệ đặc biệt, quy trình sản xuất, hoặc thông tin khác (như một khóa cá nhân hoặc các tham số bí mật khác, đặc tả thuật toán hoặc chi tiết thiết kế khác), điều đó là tài sản đối với nhà sản xuất hoặc nhà cung cấp và liên quan tới mật mã trong sản phẩm đó, đối với Bên hoặc người trong lãnh thổ của Bên đó;

B. đối tác với người trong lãnh thổ của mình; hoặc

C. sử dụng hoặc tích hợp thuật toán mật mã đặc biệt hoặc mật mã, khác với nơi sự sản xuất, bán hàng, phân phối, nhập khẩu hoặc sử dụng sản phẩm đó bởi hoặc vì chính phủ của Bên đó.

 

Mô tả đặc điểm điều khoản đó của USTR chắc chắn dường như đã thuyết phục được cựu thư ký về chính sách An toàn Nội địa và luật sư của NSA, Stewart Baker, người cho tới nay đã tuyên bố trên tờ Washington Post rằng USTR thắng cuộc chiến mật mã. Trong giải thích của ông, điều khoản đó có lẽ ngăn một quốc gia TPP khỏi việc yêu cầu một nhà cung cấp phần mềm mật mã cung cấp nó với một cửa hậu hoặc “chìa khóa vàng”, dạng mà các nhà chức trách ép tuân thủ luật đã từng đòi hỏi và điều mà chúng tôi đã lên án mạnh mẽ và nhất quán.

 

Những đây là một giải thích quá màu hồng, vì vài lý do. Quan trọng nhất, điều khoản được trích dẫn ở trên ngay lập tức đi kèm sau bằng một ngoại lệ nơi mà một nhà cung cấp dịch vụ sử dụng mã hóa có thể vẫn được yêu cầu cung cấp các giao tiếp không được mã hóa cho các cơ quan ép tuân thủ luật, tuân theo “các thủ tục pháp lý”. Vì đây thực sự là tất cả những gì các nhà chức trách ép tuân thủ luật làm sau đó, thực tế là một nhà cung cấp thực sự không thể bị ép phun ra khóa cá nhân thực sự mà họ đang sử dụng, vấn đề hoàn toàn khó.

 

Nhưng, vì lợi ích của lý lẽ, giả thiết chính phủ muốn khóa cá nhân của một sản phẩm, thay vì chỉ các giao tiếp được giải mã, TPP vẫn cho phép họ cách để có nó. Chương về các Rào cản Kỹ thuật cho Thương mại chỉ là về các tiêu chuẩn với chúng các sản phẩm phải tuân thủ để được phê chuẩn cho thương mại. Vì thế nó cấm yêu cầu rằng một khóa cá nhân cho phép mã hóa được chuyển qua như một điều kiện sản xuất, phân phối bán hàng, nhập khẩu hoặc sử dụng sản phẩm đó. Nhưng nó không thể làm bất kỳ điều gì để ngăn cản chính phủ khỏi việc tìm một lệnh của tòa án chống lại nhà cung cấp phần mềm đòi hỏi nó phải mở ra khóa cá nhân đó của sản phẩm mà được đưa vào thị trường hoặc được cung cấp một cách hợp pháp bên trong một quốc gia.

 

Hơn nữa, chương về các Ngoại lệ và các Điều khoản Chung nêu rằng “Không gì trong Hiệp định này sẽ được xây dựng để... loại trừ một Bên khỏi việc áp dụng các biện pháp mà nó xem là cần thiết cho việc thi hành các bổn phận của nó về khía cạnh duy trì hoặc phục hồi hòa bình hoặc an ninh quốc tế, hoặc bảo vệ các lợi ích an ninh cơ bản của riêng nó”. Điều này đưa ra nền tảng cơ bản cho chính phủ đè lên Phụ lục 8-B hoàn toàn nếu nó có thể nói rằng nó cân nhắc tới sự cần thiết phải làm thế vì các lý do an ninh quốc gia.

 

Dường như các lỗ hổng ở trên từng là không đủ, biết rằng điều khoản trong Phụ lục 8-B chỉ có hiệu lực đối với các quốc gia TPP khác. Điều này ngụ ý rằng, nếu, ví dụ, chính phủ Mỹ ép buộc một sản phẩm mã hóa làm trong nước như Wickr để nhúng một cửa hậu mã hóa, có thể không có hạn chế thương mại giữa các quốc gia TPP và vì thế không yêu cầu hành động nào theo TPP được.

 

Tình huống tương tự có thể tồn tại đối với các sản phẩm từ các nước không nằm trong TPP; không gì có thể ngăn được một nước TPP khỏi việc yêu cầu các lập trình viên của, ví dụ, Telegram, hãng có trụ sở ở Đức, để lại cửa hậu trong phần mềm của họ. Một khiếu nại theo TPP chỉ có thể nảy sinh nếu quốc gia nó yêu cầu truy cập cửa hậu tới sản phẩm mã hóa, và nước mà từ đó sản phẩm được phát triển hoặc được cung cấp, đều là các bên ký kết khác của TPP.

 

Vì thế những gì nổi lên trên bề mặt là sự bảo vệ mạnh cho phần mềm mật mã trong TPP thực sự là yếu hơn nhiều so với nói dường như có: nó không ngăn chặn chính phủ khỏi việc yêu cầu các nhà cung cấp trao cho họ sự truy cập tới các dữ liệu được giải mã, nó không bảo vệ được các lập trình viên chống lại các đòi hỏi cửa hậu từ chính phủ của riêng họ, nó không bảo vệ các công cụ từ các quốc gia không phải là các bên ký kết TPP, nó không dừng được một quốc gia khỏi việc đòi hỏi truy cập tới các khóa cá nhân của một sản phẩm miễn là đòi hỏi này không là một điều kiện cung cấp sản phẩm đó trong quốc gia đó, và trên tất cả rằng, có một ngoại lệ về an ninh quốc gia bao quát chung mà có thể đè lên toàn bộ điều khoản đó.

 

Quá nhiều để chiến thắng cuộc chiến mật mã.

 

The U.S. Trade Representative (USTR) fears the grassroots tech community, and rightly so. Internet users are the community that killed SOPA and PIPA in the U.S. Congress and ACTA in the European Parliament. The USTR is right to fear that the same could happen to the Trans-Pacific Partnership agreement (TPP).

That's why they've taken such pains to present the TPP as being friendly to the Internet and tech users and have included a few provisions in the agreement that they can point to to justify this claim. We've covered (and debunked) some of these before—notably the free flow of information rules common to both TISA and the TPP—but there's another that deserves comment.

Under the heading “How the TPP Protects the Internet and Ensures Digital Freedom,” the USTR claims on its website that the TPP “ensures that companies and individuals are able to use the cybersecurity and encryption tools they see fit, without arbitrary restrictions that could stifle free expression.” This refers to a heretofore obscure provision hidden away in Annex 8-B of the Technical Barriers to Trade [PDF] chapter of the TPP, which provides:

With respect to a product that uses cryptography and is designed for commercial applications, no Party may impose or maintain a technical regulation or conformity assessment procedure that requires a manufacturer or supplier of the product, as a condition of the manufacture, sale, distribution, import or use of the product, to:

A. transfer or provide access to a particular technology, production process, or other information (such as a private key or other secret parameter, algorithm specification or other design detail), that is proprietary to the manufacturer or supplier and relates to the cryptography in the product, to the Party or a person in the Party’s territory;

B. partner with a person in its territory; or

C. use or integrate a particular cryptographic algorithm or cipher, other than where the manufacture, sale, distribution, import or use of the product is by or for the government of the Party.

The USTR's characterization of these provision certainly seems to have convinced former Homeland Security policy secretary and NSA lawyer, Stewart Baker, who went so far as to proclaim in the Washington Post that the USTR wins the Crypto War. In his interpretation, the provision would prevent a TPP country from requiring a supplier of cryptographic software to provide it with a backdoor or “golden key," of the kind that law enforcement authorities have been demanding and that we have consistently and strongly denounced.

But this is much too rosy an interpretation, for several reasons. Most importantly, the provision quoted above is immediately followed by an exception whereby a service provider that uses encryption can still be required to provide unencrypted communications to law enforcement agencies pursuant to “legal procedures.” Since this is really all that law enforcement authorities are after, the fact that a provider can't actually be forced to disgorge the actual private key they are using, hardly matters at all.

But, for the sake of argument, supposing the government does want a product's private key, rather than just the decrypted communications, the TPP still allows them a way to get it. The Technical Barriers to Trade chapter is only about standards with which products must comply in order to be approved for commerce. Thus it prohibits the requirement that a private key allowing decryption be handed over as a condition of manufacture, sale distribution, import or use of the product. But it wouldn't do anything to prevent the government from seeking a court order against a software vendor requiring it to disclose the private key of a product that is lawfully marketed or supplied within the country.

Further, the Exceptions and General Provisions chapter provides that “Nothing in this Agreement shall be construed to … preclude a Party from applying measures that it considers necessary for the fulfilment of its obligations with respect to the maintenance or restoration of international peace or security, or the protection of its own essential security interests.” This lays the foundation for a government to override Annex 8-B altogether if it can claim that it considers it necessary to do so for national security reasons.

As if the above loopholes weren't large enough already, consider that the provision in Annex 8-B is only enforceable by other TPP countries. This means that if, say, the United States government compelled a home-grown encryption product such as Wickr to embed an encryption backdoor, there would be no restriction of trade between the TPP countries and thus no actionable claim under the TPP.

A similar situation would exist for products from non-TPP countries; nothing would prevent a TPP country from requiring the developers of, for instance, Telegram which is based in Germany, to backdoor their software. A claim under the TPP would only arise if the country demanding backdoor access to an encryption product, and the country from which that product is developed or supplied, are both different TPP signatories.

So what appears on the surface to be strong protection for crypto software in the TPP is actually much weaker than it seems: it doesn't prevent the government from requiring providers to give them access to decrypted data, it doesn't protect developers against backdoor demands from their own government, it doesn't protect tools from countries that aren't TPP signatories, it doesn't stop a country from demanding access to private keys of a product so long as this demand is not a condition of supply of that product within the country, and on top of all that, there is a sweeping national security exception that can override the provision altogether.

So much for winning the crypto wars.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Bạn đã không sử dụng Site, Bấm vào đây để duy trì trạng thái đăng nhập. Thời gian chờ: 60 giây