It's an inherent weakness in RSA, to generate random prime numbers. In theory, if the attacker knew what method was being used, instead of trying to prime-factorize the modulus by brute force, he or she could just use the same random-prime generating scheme in their attack, that the defender used, and speed up the attack.

Hence, true RSA encryption uses only a small subset of the existing, huge prime numbers.

But then what I'd expect, is that this vulnerability does not extend to users or admins, who were not using the same random-number generating method. In this article: (Suggested Above), the security software was named "BSafe". How would it affect Linux-based Web admins, who never used the compromised generator(s), and who never used BSafe?

In such a way, that it's become harder for unauthorized programs to flash the BIOS at all? In that case, how many attacks they prevented is truly speculative. And the speculation, that they must have patched the BIOS themselves, secretly, would be unfounded.

I'm sorry that I argued against your idea so energetically - and ultimately falsely.

I suppose that my information is grossly out-of-date. In response to your most recent posting, I looked up this subject on the Web, and found an article which confirms what you are saying:

External Reference

In particular, this article states that a BIOS update can be performed in some cases, by double-clicking on an .EXE File, which is by far different from what I had to do (only in 2011, for a contemporary computer) using a USB stick and an .ROM File.

But then I must also admit, that the possible answers to the whole NSA question change completely as well. Since the BIOS can be flashed behind our backs, there is indeed little allowing the general public to know whether 'The BIOS Plot' as such was real, nor what the NSA could have done about it. At that point there is some slight plausibility, even for the idea of the NSA having used that - or having used some other back door - to get into our computers.

What you're telling me, is that when I booted my BIOS into Admin mode, after I had given the command to Windows to reboot, when I told the BIOS to Update to a .ROM File, which it finds in the root directory of the USB stick I just inserted, the existing BIOS should have checked the signature of that (new) ROM Image, before accepting it. And so a failure to enforce a signature, would become a failure in the existing BIOS. Which has already been shipped in millions of computers.

Well while this type of signature-checking does exist with Secure Boot, (a) it requires hardware-support at that, and (b) applies to operating systems, not BIOS ROM Images.

You have suggested we look at the hash-tag #badBIOS , to see the system in action, that deploys PC firmware updates via Windows. This is one of the several articles written on the Web about this, all from the same guy, who goes by the name "Ruiu": Suggested Link What I find the most dubious about all this, is the ability "to transmit small amounts of network data with other infected machines even when their power cords and Ethernet cables were unplugged and their Wi-Fi and Bluetooth cards were removed." Also note, "(badBIOS) has the ability to use high-frequency transmissions passed between computer speakers and microphones to bridge airgaps." Can I be forgiven for not taking such claims seriously? To the best of my own knowledge, (1) Actual BIOS updates are infrequent, not a part of any routine workflow. (2) Even though virus-writers can use them to cripple computers - via a running O/S - SysAdmins can't use them unless they shut down the computer first, precisely because they do not work as described in this article. (3) Attempts are frequently made to bypass Protected Memory on the O/S, to result in viruses gaining access to all the hardware. But this cannot - presently - be used to produce a changed BIOS which works normally. (4) Instead of using floppy disks, we use USB sticks today. We put a file onto that USB drive, which has the filename extension .ROM . It stands for 'a ROM Image'. And because some advanced File Systems require than special drivers be loaded, even in this day and age we format those USB sticks with FAT32, just in case. (5) It's considered gauche, if there is even more than one .ROM File on the stick, even though technically, the BIOS itself, booted into admin mode, displays the .ROM Files in a list, for the user to choose from.

Since a legitimate BIOS Update, which leads to a working BIOS, takes place between a USB Stick, physically connected to a computer's Motherboard, whose O/S has been shut down, where exactly did the BIOS Update Workflow need to be fixed?

My observation for the moment would be, that if this thing was disguised as a software- or a firmware-update, it would not seem to have been targeting the most secure servers. Because unlike personal users, server admins don't usually fall for that kind of trick. And thankfully, most of the servers that actually 'run the economy', so to speak, are in the hands of people who can distinguish between a real update, and a fake one. I'm not sure whether those guys actually tend to update their BIOS often though. I'd think that if one of their Motherboards was giving them trouble, they'd just replace a whole server rack - with MBs that did perform well from day 1. /That kind/ of server-room doesn't receive many fake update-requests, of the sort that would fool non-experts, because each server isn't managed by a user as such. In that environment all the servers are managed by something like ~a Hypervisor~ , and most of them don't actually have monitors, to display confusing graphics... But then, how would this request have crippled the Economy? What's described might at best have crippled a whole bunch of PCs, which was the starting assumption of this whole article.

What your comment suggests, is that a targeted attack is possible against commercially-critical computers, and which exploits a vulnerability for code injection into the BIOS, with the aim of just disabling them. But you are also implying (as was the NSA), that the solution to this vulnerability was with the BIOS itself, _or_ with the Motherboard. And so it's a bit of a foregone conclusion, that the solution is to enhance BIOS-level encryption. AFAIK, Secure Boot etc., limit what types of O/S kernels can boot, based on encryption. I've never heard of Secure Boot blocking an attempted BIOS Flash, only of the Motherboard manufacturers making sure on their end, that functioning BIOS versions re-incorporate Secure Boot. Hence, if you were able to find an incompatible BIOS version that _would_ brick your machine, Secure Boot won't prevent you from inserting the USB stick and doing so. However, if the goal is to prevent arbitrary code execution, that has access to the whole hardware - which it's not supposed to in general - then the responsibility lies with the O/S. Whether the NSA got involved or not.

AFAIK, result in a BIOS which no longer works. This will be different from a PC, which has been rescued by the NSA, in a way that's obvious to the user.

Well in addition to owning a dual-boot laptop that was manufactured in 2005, I own a Windows 7 -running PC, which urgently required a BIOS Flash. The reason was, the fact that this Windows-7 box was overclocked as shipped, which is now accomplished via a custom BIOS. Such a custom BIOS already likely has errors, other than the overclocking, causing obvious stability problems. Well in order to do this, I needed a USB Memory Stick, formatted with FAT32, even though this computer was built around 2011. The manufacturer was not able to do it with me, through a running O/S. How would a floppy disk be relevant? But, if all you want to do is brick the computer, then I'd say all you need is a successful attempt to flash the BIOS, while the O/S is running. It's done at that point. Besides which, my overclocked PC proved, that every MB requires its own, exact BIOS version. How did the NSA get all the BIOS versions straight, for presumably millions of computers?

At least, if it's to produce a malware-running BIOS version. But wait a moment. What they wrote, is that the plot from China was only supposed to produce bricked computers. I've mainly heard of computers bricked because the user actually flashed his BIOS - and made some sort of mistake. So an attempt just to brick one could be targeted and might work, with Windows running. In any case, it would be hard for (China) to do this on my dual-boot laptop built in 2005, because I mainly run it in Linux mode, and Linux is so much more resilient to such things. And, I was able to install Linux on it, precisely because it *doesn't* have secure-boot.

One needs to consider, whether claims that we hear and read are plausible. Just where did the NSA fix a BIOS vulnerability, on one of my computers, which was built in 2005? I never flashed the BIOS on this machine, and neither did they. But we do know that very conspicuously, Microsoft came out with Secure-Boot more recently, and "in cooperation with manufacturers". It's likely that this is what the NSA is referring to - behind some obfuscated ways of speaking...

I suppose that this also means, is that all the Linux computers, installable on PCs without secure-boot, have by now been destroyed by China.

There are alternatives, but they all work differently. Thus between 50 people, I don't see how useful pure file sharing remains. Instead, you might want to go with one of the popular Web Content Management Systems, or WCMS. "eGroupware" is just one, free example. But then don't expect to drag-and-drop files.

I think one needs to realize that MS became a de-facto standard, and that Samba is a Linux emulation of it. From what I see here, Samba4 also does Active Directory. But then it becomes a Linux re-implementation of A/D. Is it highly important to emulate pure file sharing at all? I once told myself that file sharing via a File Server may be a wrong approach to some problems, except when I'm copying and pasting some files here at home, between a mere 5 personal boxes. Even between my 5 home boxes, I've run in to Samba hiccups. It's true that Samba is even accepted by my Windows 7 Pro, 64-bit client, while running on a Linux server. But it's a wavelike phenomenon based on Windows popularity. /There should/ be better ways to go, for large enterprises. Mind you as sincere as I am, the main alternatives I can think of, are probably too Linux-centric for you. I.e. you could do an NFS mount, a Unison sync via SSH, some form of WCMS, some form of OpenVPN / SSH tunneling, etc..