Phản bội mật mã của NSA: Là tin tốt lành cho nguồn mở?

NSA's Crypto Betrayal: Good News for Open Source?

By Glyn Moody, Published 14:03, 10 September 13

Theo: http://blogs.computerworlduk.com/open-enterprise/2013/09/nsas-subversion-of-encryption-good-news-for-open-source/index.htm

Bài được đưa lên Internet ngày: 10/09/2013

Lời người dịch: NSA tìm mọi cách làm suy yếu mã hóa Internet, điều ai cũng đã rõ cho tới lúc này. Để sửa điều này, không thể ai khác, chắc chắn không thể là các công ty nguồn đóng với các mã đóng không ai có thể nhìn thấy (“Tôi đã viết rồi về cách thức mà Microsoft đã và đang làm điều này thông qua việc cung cấp các khai thác ngày số không cho NSA để NSA sử dụng để đột nhập vào các hệ thống của các tập đoàn và chính phủ”), mà phải là các cộng đồng phần mềm tự do nguồn mở có trách nhiệm mới có khả năng để khắc phục, dù đây là một công việc với trách nhiệm khổng lồ, khó khăn. Đó là tinh thần của bài viết này. “Hãy nhớ trong đầu điều này: biết rằng sự đồng lõa của các công ty phần mềm thương mại trong hệ thống gián điệp toàn cầu của NSA, phần mềm tự do là hy vọng duy nhất chúng ta có để giành lại một chút riêng tư và an ninh trên trực tuyến”. Xem thêm: 'Chương trình gián điệp PRISM trên không gian mạng'.

Những phát hiện từ các tài liệu mà người thổi còi Edward Snowden có được rằng GCHQ về cơ bản tải về toàn bộ Internet khi nó vào và ra khỏi nước Anh, và lưu trữ đống khổng lồ của nó, là đủ tồi tệ. Nhưng tuần trước chúng ta đã biết được rằng NSA đã cố tình làm suy yếu đúng là từng khía cạnh của mã hóa trực tuyến:

Các cơ quan, các tài liệu phát hiện, đã áp dụng một bộ các phương pháp trong cuộc tấn công có hệ thống và liên tục của họ vào những gì họ coi như là một trong những mối đe dọa lớn nhất cho khả năng của họ để truy cập được các băng khổng lồ giao thông Internet - “sử dụng mã hóa khắp nơi khắp Internet”.

Các phương pháp bao gồm các biện pháp giấu giếm để đảm bảo sự kiểm soát của NSA đối với việc thiết lập các tiêu chuẩn mã hóa quốc tế, sử dụng các siêu máy tính để phá mã hóa với “sự ép buộc vũ phu” và - bí mật được canh phòng cẩn mật nhất của tất cả - hợp tác với các công ty công nghệ và bản thân các nhà cung cấp dịch vụ Internet.

Chính điểm cuối đó mà tôi muốn tập trung vào ở đây - thực tế là các công ty máy tính là đồng lõa trong việc làm xói mòn an ninh mà chúng ta từng nghĩa chúng ta từng sử dụng để bảo vệ tính riêng tư của chúng ta. Tôi đã viết rồi về cách thức mà Microsoft đã và đang làm điều này thông qua việc cung cấp các khai thác ngày số không cho NSA để NSA sử dụng để đột nhập vào các hệ thống của các tập đoàn và chính phủ. Đó có thể chỉ là những cơ hội ngắn hạn, vì Microsoft sau đó sẽ sửa các lỗi đó.

Những gì chúng ta đang làm việc với bây giờ là nghiêm túc hơn nhiều. Việc cung cấp các chỗ bị tổn thương ngày số 0 có thể được gọi là tội ác của sự bỏ qua - không cảnh báo người sử dụng rằng các hệ thống của họ có khả năng bị tổn thương. Thông tin mới nhất chỉ ra rằng các công ty cũng đang phạm tội ủy thác: cho phép các lỗi được xây dựng cố ý trong các sản phẩm an ninh mà họ bán. Đây là những gì mà bài báo trên tờ Guardian từ tuần trước nêu về điều này:

Trong số những điều khác, chương trình được thiết kế để “chèn các chỗ bị tổn thương vào các hệ thống mã hóa thương mại”. Chúng có thể được biết đối với NSA, nhưng không với ai khác nữa, bao gồm cả những khách hàng thông thường, những người đang được tham chiếu một cách ấn tượng tới trong tài liệu như là “các kẻ địch”.

“Những thay đổi thiết kế đó đã làm cho các hệ thống đáng ngờ có khả năng bị khai thác thông qua thu thập tình báo dấu hiệu Sigint... với sự biết trước về sự sửa đổi. Tuy nhiên, đối với người tiêu dùng và các kẻ địch khác, thì an ninh hệ thống vẫn không sứt mẻ gì”.

Như đoạn sau đây làm rõ, mối quan hệ gắn bó này rất giống viên ngọc trên vương miện rình mò của NSA:

Một chỉ dẫn bí mật của NSA chung hơn phát hiện nhiều chi tiết hơn về các quan hệ đối tác sâu của cơ quan đó với giới công nghiệp, và khả năng của nó để sửa đổi các sản phẩm. Nó cảnh báo các nhà phân tích rằng 2 sự việc phải giữ tuyệt mật: là NSA tiến hành những sửa đổi đối với các phần mềm và thiết bị mã hóa thương mại “để làm cho chúng có khả năng khai thác được”, và rằng NSA “giành lấy các chi tiết mật mã của các hệ thống an ninh thông tin mật mã thương mại thông qua các mối quan hệ với giới công nghiệp”.

Đó là, bây giờ giả thiết phải là mỗi sản phẩm an ninh của Mỹ từng bị làm xói mòn theo cách này (và có lẽ nhiều sản phẩm từ các nước khác cũng vậy, vì Mỹ có lẽ không là quốc gia duy nhất tham gia vào thực tiễn này). Điều đó tăng cường thêm cho những gì tôi đã viết trước đó: các công cy thực sự đang lơ là nếu họ phụ thuộc vào phần mềm thương mại, vì phạm vi đối với gián điệp công nghiệp là khổng lồ. Quả thực, trong vài ngày qua chúng ta đã phát hiện rằng bản thân NSA tham gia vào trong vụ gián điệp như vậy. Những gì gây lo lắng là bằng việc đặt các cửa hậu vào các hệ thống an ninh chủ chốt, NSA cũng đã làm gia tăng nhiều khả năng các tác nhân khác - cả các quốc gia và bọn tội phạm - đang khai thác chúng để truy cập các thông tin bí mật của các tập đoàn.

Vì thế, câu hỏi rõ ràn sẽ trở thành: nguồn mở thì thế nào? Liệu nó có chịu các vấn đề y hệt như phần mềm nguồn đóng hay không, hay liệu qui trình phát triển cộng tác mở của nó có ngăn chặn được các cửa hậu ẩn giấu như vậy được không? Rõ ràng còn quá sớm để trả lời câu hỏi đó một cách dứt khoát, nhưng đây là vài trường hợp trao cho chúng ta ý nghĩa của các vấn đề có liên quan.

Đầu tiên, một bài viết từ Theodore Ts'o, một trong những cao thủ Linux cao cấp nhất, và vẫn còn đưa ra các quyết định tốt lành như thế này:

Tôi rất vui vì tôi đã chống lại các kỹ sư của Intel để /dev/random chỉ dựa vào lệnh RDRAND. Trích từ bài báo bên dưới [một trong các báo cáo gần đây về việc NSA làm suy yếu ann ninh Internet tại www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html]:

“Tới năm nay, Dự án Sigint Enabling đã tìm thấy các cách thức bên trong một số chips mã hóa mà thông tin thu thập được đối với các doanh nghiệp và các chính phủ, hoặc bằng cách làm việc với các nhà sản xuất chip để chèn vào các cửa hậu...”

Chỉ dựa vào bộ sinh số ngẫu nhiên của phần cứng mà đang sử dụng một sự triển khai được đóng si bên trong một con chip mà không có khả năng để kiểm toán là một ý tưởng TỒI.

Rồi ở đó có một luồng thảo luận quyến rũ và minh họa về những mối nguy hiểm của nguồn đóng, các triển khai phần cứng, các cửa hậu và các vấn đề nảy sinh đối với nguồn mở - tôi khuyến cáo đọc ít nhất một số trong đó để có được ý tưởng của các vấn đề ở đây.

Mặt khác, đây là một ví dụ nơi mà qui trình nguồn mở dường như không giúp được nhiều. Câu chuyện bắt đầu với sự triển khai của Red Hat mật mã hình ellip (ECC) trong gói OpenSSL được sử dụng rộng rãi. Ngược về năm 2007, một thẻ Bugzilla từng được mở về các tính năng nhất định mà đã được vô hiệu hóa vì các vấn đề có khả năng về bằng sáng chế. Điều đó là đủ tệ, nhưng như Dietrich Schmitz đã phát hiện khi ông đã khám phá câu chuyện của Red Hat, hóa ra là không chỉ triển khai của Red Hat có các vấn đề. Một bài viết của kỹ sư Mike Hearn của Google giải thích:

Hôm nay tôi đã học được (thông qua Gregory Maxwell) rằng qui trình tuyển chọn các tham số đường “ngẫu nhiên” [đối với ECC] dường như ở trên bề mặt sẽ là hoàn toàn đáng ngờ. Các tham số đó là đầu ra của SHA1, nó sẽ là tốt nếu hạt nhân được chọn theo một cách thức có thể tái sinh được. Nhưng chúng đã không thế. Các hạt nhân là các hằng số cực kỳ lớn và không có những giải thích chúng tới từ đâu. Điều đó bốc mùi rất nặng về thứ gì đó có thể bị đột nhập.

Điều còn tốt hơn. Hóa ra là những hằng số đó không chỉ là không có khả năng giải thích, mà thực sự được tạo ra bởi một nhân viên của NSA. Và hóa ra là nhóm làm việc IEEE đã từng làm việc về các tiêu chuẩn cho ECC thực sự tổ chức các cuộc họp của mình trong các khu nhà của NSA và đối tác của nó và vì thế cũng đã được NSA phê chuẩn.

Nói một cách khác, NSA đã từng có khả năng thiết lập vài hằng số chủ chốt mà hầu hết chắc chắn làm dễ dàng hơn nhiều cho nó để truy cập các dữ liệu được mã hóa bằng việc sử dụng kỹ thuật đặc biệt này. Điều lo lắng ở đây là không ai trong thế giới nguồn mở dường như đã lo lắng về điều này theo cách mà Ts'o đã lo lắng tới điểm từ chối tuân theo một gợi ý mà ông đã không hài lòng.

Điều này nhắc nhở chúng ta rằng sự minh bạch được ca tụng nhiều của nguồn mở (ít nhất không phải tôi) tất cả là rất tốt, nhưng nó phụ thuộc vào các kỹ sư đa nghi đang sử dụng tính mở đó để kiểm tra và thách thức các quyết định thiết kế. Bây giờ, đúng là sự phá vỡ của NSA đã diễn ra bên trong nhóm làm việc về các tiêu chuẩn, và rằng nguồn mở không thể phụ thuộc thậm chí vào các cơ quan tiêu chuẩn đáng kính trên danh nghĩa để tạo ra các thiết kế mà không chứa các cửa hậu.

Quả thực, John Gilmore, đồng sáng lập của EFF, đã viết một bài thú vị về một số điều ông đã thấy xảy ra trong ủy ban IETF khi thiết kế tiêu chuẩn IPsec:

Các nhân viên NSA đã tham gia khắp, và chiếm các vai trò lãnh đạo trong ủy ban và trong số những biên tập các tài liệu

…

Mỗi lần, ai đó không phải là nhân viên của NSA, nhưng người đã có các mối quan hệ lâu dài với NSA, có thể gợi ý tính riêng tư hoặc an ninh bị giảm sút đó, nhưng điều đó dường như có ý nghĩa khi được xem xét bởi những người không biết nhiều về mật mã.

…

Tiêu chuẩn kết quả là cực kỳ phức tạp - nên phức tạp rằng mỗi nhà mật mã học thực sự mà đã cố gắng phân tích nó từng vung tay họ ra và nói, “Chúng tôi không thể thậm chí bắt đầu đánh giá an ninh của nó trừ phi bạn đơn giản hóa nó tận gốc”.

Vì thế tin tốt lành là nguồn mở chắn chắn tốt hơn so với mã nguồn đóng khi nói về các cửa hậu vì dễ dàng hơn để tìm ra chúng - miễn là ai đó thực sự tìm kiếm chúng. Tin xấu là NSA đã đầu độc an ninh ở mức thậm chí sâu hơn chúng ta tưởng, làm bại hoại bản thân các tiêu chuẩn về an ninh.

Các tác động của những rò rỉ mới đó là nhiều. Trước tiên, tất cả các dự án triển khai các tính năng an ninh nên kiểm tra mã của chúng để xem liệu nó có bị can thiệp theo cách thức nào đó hay không. Có là là không, nhưng không có gì là không thể cả, và chắc chắn điều này NSA đã cố thử rồi.

Sau đó, họ nên kiểm tra lịch sử mã trong trường hợp từng có bất kỳ sự đóng góp “hữu dụng” nào từ NSA hoặc những người có thể có quan hệ với họ. Thậm chí trong sự thiếu vắng “sự trợ giúp” như vậy, thì bất kỳ quyết định không bình thường nào cũng nên bị hỏi thăm. Việc kiểm tra các tiêu chuẩn nằm bên dưới là một nhiệm vụ lớn hơn mà sẽ đòi hỏi các kỹ sử nguồn mở từ các dự án khác nhau để lôi ra các kỹ năng của họ, nhưng điều đó phải được thực hiện. Cuối cùng, các dự án nguồn mở cần phải thiết kế các chỉ dẫn cho sự phát triển mã trong tương lai mà sẽ giúp tránh được các vấn đề sâu đó ngay từ đầu.

Tôi nhận thức được rằng nắm tất cả lại, điều này đại diện cho một nhiệm vụ mênh mông. Nhưng điều đó phản ánh mức độ của sự phản bội mà chúng ta đã phát hiện ra ở đây. NSA đã cố ý hủy hoại toàn bộ kiến trúc lòng tin trực tuyến, thuần túy vượt ra khỏi một mong muốn ích kỷ để làm cho công việc gián điệp của nó lên mọi người, mọi nơi, mọi lúc, dễ dàng hơn.

Bất kể sự lan truyền chính trị thế nào những phát hiện về sự giám sát ồ ạt có thể có, và bất kể sức ép nào được áp đặt và hứa hẹn nào được thực hiện, thì sự việc đơn giản là cộng đồng nguồn mở có thể không bao giờ tin các cơ quan tiêu chuẩn hoặc sự tham gia của chính phủ trong các dự án một lần nữa. Quả thực, thế giới phần mềm tự do phải dựa chỉ vào cộng đồng các kỹ sư của riêng nó, và thậm chí sau đó phải đặt câu hỏi cho mọi điều mà họ tạo ra.

Nếu điều đó nghe có vẻ quá nặng nề, hãy nhớ trong đầu điều này: biết rằng sự đồng lõa của các công ty phần mềm thương mại trong hệ thống gián điệp toàn cầu của NSA, phần mềm tự do là hy vọng duy nhất chúng ta có để giành lại một chút riêng tư và an ninh trên trực tuyến. Điều đó có thể là một trách nhiệm khổng lồ, đáng sợ cho một nhóm những tình nguyện viên nghèo để nhớ, nhưng điều đó không phải là trách nhiệm mà có thể bị bất kỳ ai tránh né, những người quan tâm về tự do số.

Revelations f-rom documents obtained by whistleblower Edward Snowden that GCHQ essentially downloads the entire Internet as it enters and leaves the UK, and stores big chunks of it, was bad enough. But last week we learned that the NSA has intentionally weakened just about every aspect of online encryption:

The agencies, the documents reveal, have adopted a battery of methods in their systematic and ongoing assault on what they see as one of the biggest threats to their ability to access huge swathes of internet traffic - "the use of ubiquitous encryption across the internet".

Those methods include covert measures to ensure NSA control over setting of international encryption standards, the use of supercomputers to break encryption with "brute force", and - the most closely guarded secret of all - collaboration with technology companies and internet service providers themselves.

It's that last point that I want to focus on here - the fact that computer companies are complicit in undermining the security we thought we were using to protect our privacy. I've already written about the way that Microsoft has been doing this through providing zero-day exploits to the NSA for it to use to break into corporate and government systems. Those are probably only short-term opportunities, since Microsoft does then go on to fix the bugs.

What we are dealing with now is much more serious. Providing zero-day vulnerabilities might be called sins of omission - failing to warn users that their systems are vulnerable. The latest information shows that companies are also committing sins of commission: allowing flaws to be built in to the purportedly secure products they sell. Here's what the Guardian article f-rom last week goes on to say on this:

Among other things, the program is designed to "in-sert vulnerabilities into commercial encryption systems". These would be known to the NSA, but to no one else, including ordinary customers, who are tellingly referred to in the document as "adversaries".

"These design changes make the systems in question exploitable through Sigint collection … with foreknowledge of the modification. To the consumer and other adversaries, however, the systems' security remains intact."

As the following paragraph makes clear, this close relationship is very much the jewel in the NSA's snooping crown:

A more general NSA classification guide reveals more detail on the agency's deep partnerships with industry, and its ability to modify products. It cautions analysts that two facts must remain top secret: that NSA makes modifications to commercial encryption software and devices "to make them exploitable", and that NSA "obtains cryptographic details of commercial cryptographic information security systems through industry relationships".

That is, the assumption must now be that every US security product has been undermined in this way (and probably many f-rom other countries too, since the US is unlikely to be the only nation to engage in this practice.) That reinforces what I've written before: companies are really being negligent if they depend on commercial software, since the scope for industrial espionage is huge. Indeed, in the last couple of days we have discovered that the NSA itself is engaged in such espionage. What's troubling is that by placing backdoors in key security systems the NSA has also greatly increased the likelihood that other actors - both nations and criminal - are exploiting these to access confidential corporate information.

So, the obvious question then becomes: what about open source? Does it suffer f-rom the same problems as closed-source software, or does its open collaborative development process prevent such backdoors f-rom being hidden? It's obviously far too early to answer that question definitively, but here are a couple of cases that give us a sense of the issues involved.

First, a post f-rom Theodore Ts'o, one of the most senior Linux hackers, and still making good decisions like this:

I am so glad I resisted pressure f-rom Intel engineers to let /dev/random rely only on the RDRAND instruction. To quote f-rom the article below [one of the recent reports on NSA's weakening of Internet security at www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html]:

"By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to in-sert back doors...."

Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.

There then follows a fascinating and illuminating discussion thread about the dangers of closed source, hardware implementations, backdoors and the issues raised for open source - I recommend reading at least some of it to get an idea of the issues here.

On the other hand, here's an example whe-re the open source process doesn't seem to have helped much. The story starts with Red Hat's implementation of elliptic curve cryptography (ECC) in the widely-used OpenSSL package. Back in 2007, a Bugzilla ticket was opened about certain features that had been disabled because of possible patent issues. That's bad enough, but as Dietrich Schmitz discovered as he explored the Red Hat story, it turns out that it's not just Red Hat's implementation that has problems. A post by the Google engineer Mike Hearn explains:

today I learned (via Gregory Maxwell) that the process for se-lecting the "random" curve parameters [for ECC] appears on the surface to be completely implausible. The parameters are the output of SHA1, which should be good if the seed was se-lected in a reproducible manner. But they were not. The seeds are extremely large constants with no explanations of whe-re they came f-rom. That smells very strongly of something that might be hacked.

It gets better. It turns out that these constants are not only unexplainable but were actually generated by an employee of the NSA. And it turns out that the IEEE working group that worked on standards for ECC was actually holding its meetings on the NSA campus and its membership therefore had to be approved by the NSA as well.

In other words, the NSA has been able to set a couple of key constants that almost certainly make it far easier for it to access data encrypted using this particular technique. What's worrying here is that nobody in the open source world seems to have worried about this in the way that Ts'o was worried to the point of refusing to follow a suggestion he was not happy with.

This reminds us that open source's much-vaunted (not least by me) transparency is all very well, but it depends on sceptical engineers using that openness to check and challenge design decisions. Now, it's true that the NSA's subversion took place within the standards working group, not during the implementation. But the moral is that henceforth the basic standards should be suspect, and that open source cannot depend even on nominally respected standards bodies to produce designs that do not contain backdoors.

Indeed, John Gilmore, co-founder of the EFF, has just written a fascinating post about some of the things he saw happening in the IETF committee drawing up the IPsec standard:

NSA employees participated throughout, and occupied leadership roles in the committee and among the editors of the documents

...

Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto.

...

The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically".

So the good news is that open source is certainly better than closed-source code when it comes to backdoors, because it's much easier to find them - provided somebody is actually looking for them. The bad news is that the NSA has poisoned the security well at an even deeper level than we feared, corrupting the security standards themselves.

The implications of these new leaks are many. First, that all open source projects that implement security features should check their code to see if it has been tampered with in some way. That's unlikely, but by no means impossible, and surely something the NSA has tried.

Then, they should check the code history in case there have been any "helpful" contributions f-rom the NSA or people who might be linked to them. Even in the absence of such "help", any unusual decisions should be queried. Checking the underlying standards is a larger task that will require open source engineers f-rom different projects to pool their skills, but it must be done. Finally, open source projects need to draw up guidelines for future code development that will help avoid these deep problems in the first place.

I am aware that taken all together, this represents an immense task. But that reflects the level of the betrayal we have discovered here. The NSA has consciously ruined the entire architecture of online trust, purely out of a selfish desire to make its job of spying on everyone, everywhe-re, all the time, easier.

Whatever political fallout the revelations of that massive surveillance may have, and whatever constraints are imposed and promises made, the simple fact is that the open source community can never trust standards bodies or government participation in projects again. Instead, the free software world must depend only on its own community of engineers, and even then must question everything that they produce.

If that sounds like too much of burden, bear in mind this: given the complicity of commercial software companies in the NSA's global spying system, free software is the only hope we have of regaining a little privacy and security online. That may be a massive, intimidating responsibility for a ragtag group of volunteers to bear, but it's not one that can be avoided by anyone who cares about digital freedom.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com