Posts by RandSec 28 publicly visible posts • joined 8 Feb 2010
If you want a simple, clean, Linux OS for the family, try Peppermint OS, but on older computers. One possibility is to install Peppermint to a 32G or larger USB 3.0 or 3.1 flash drive.
Linux always has problems supporting new hardware, so if you build a new state-of-the art hardware system, you can expect Linux software problems.
Peppermint works surprisingly well as a basic browsing / email / streaming / editing / research OS. With the Chrome browser, it supports Netflix. For the family, it will play browser games, Linux games, and even some Windows games (given some effort with Wine), but absent support for the latest GPU it cannot be a true gaming machine. Since Peppermint is Linux, It will support code development, but the family probably does not care.
"What these innovators need to do is come up with a 'computer' design that can successfully isolate one processes memory from the other."
Probably we need to distinguish different types of "process," as in those which must be running close together for performance, and those which could run independently. The independent processes obviously could be on completely separate hardware, instead of on a single CPU with a single huge virtual memory.
We also need to be concerned about the way malware infects the OS and perhaps multiple BIOS chips, to affect each and every session. Even replacing the motherboard and reinstalling the OS may not clean the problem unless all other BIOS chips are clean at the same time. Apparently NSA can infect hardware disk drive controllers, which means by now some malware writers can as well. Who among us could detect that, and if we cannot, how can we know we are not infected? Why is our equipment not built to be checked?
The December 11, 2017 version of the same article makes a fairly clear statement:
"For casual gamers, the bare minimum is still 8GB but there is plenty of evidence to suggest that the upgrade to 16GB will ensure smoother gameplay.
"For serious gamers with mid-range to high-end hardware, we're almost at the point where we'd say 16GB the the minimal acceptable amount of system memory."
"For GTX 1060 or RX 580 owners who've spent $200-$250 on their graphics card, dumping another $200 on DDR4 memory is something they're probably umming and ahhing about. If you're playing games such as Battlefield 1 or in particular Call of Duty WWII and you care about being competitive, then 16GB really is a must.
"Alternatively, if you have a relatively high-end GPU such as the GTX 1070 or Vega 56 but play older, less memory-intensive games, then 8GB will no doubt be fine. But again, for these newer titles you'll ideally want 16GB."
https://www.techspot.com/article/1535-how-much-ram-do-you-need-for-gaming/
I think this IS a problem of design: It demonstrates that our current concepts of design do not work at the complexity levels we want to use. This idea of "proving a negative" is the statement that the system is too big to traverse, as most are. But little systems and scalable systems can be investigated very strongly.
It may not be practical, but it would be heartening to see a build based on small modules which can be exhaustively tested to do exactly what they should and nothing else. When we get into systems with massive state, we need designs we can scale down and test. Yes, that is not the same, but it is close.
The problem is whether such tested systems can be built in hardware. We know they can be built, to some extent, in software, although very rarely are, presumably because that is not a goal, and is not taught. In this case testing might have caught a hint of the problem, only to be dismissed so the business could benefit. That benefit is what society needs to take back.
The 6809 was a completely different era. The corporate goal was to "extend the life of the 8-bit family." It used depletion-load NMOS, not CMOS, and the processor was about as slow as RAM, minimizing the advantages of caching. The hardware interpretation cycle of fetch, decode, execute was a real thing.
The architecture was intended to fix problems known in using the 6800, not carry them along. That meant instruction (and hardware) incompatibilities were assured, which implied only assembly-language level compatibility. Unfortunately, that turned out to have an unexpected and substantial marketplace cost. Addressing modes were greatly expanded and complexly encoded which meant that machine-level debug was also more complex. Existing OEM designs needed to be redone. 20-20 hindsight lets us see the market value of full backward compatibility, even when future design will move beyond the old stuff.
The 6809 certainly did not decode 6000 instructions individually, and was not based on a central state machine. The first byte of opcode (256 choices) was decoded by logical group to start timing lines which then handled subsequent bytes if any. That implementation (extended from the 6800) turned out to be relatively simple, reliable and easy to debug, but took way too much space, and so was the end of the line.
They did end up selling full boxcar loads of 6809's to the gaming industry of the time.
AMD is not affected by Meltdown, but Intel is affected and requires a sometimes crippling patch.
AMD is affected by Spectre, in the same way as Intel, and both only have partial mitigation so far.
AMD EPYC servers have hardware encryption for VM's, which means a Spectre attack can succeed and still get only encrypted data.
"Get a MB with a write protect BIOS jumper"
The next time I order a billion more PC's for the world, I'll put that in the specs. Also for the video cards. And for the hard drive, SSD, USB, and DVD drives. And whatever else.
Until then, sadly, we can only use what we have.
1. BIOS chips are not EPROM's anymore.
2. The main "BIOS" is saved in sections of motherboard flash.
3. Video cards have their own BIOS storage.
4. If the user can re-flash the "BIOS," so can malware.
5. We can re-flash the motherboard to clean it. But can we then re-flash the also-infected video card BEFORE a restart runs infected video BIOS code and so re-infects the motherboard?
6. And then, if drive controllers can be infected, how do we re-flash THOSE?
7. Conveniently, almost every PC in the world supports hardware infection.
The point is less whether there is actual proof of this having been done, and more that there is no reason why someone who worked at it could not do it. We know that NSA, for example, tries everything they can. And their opponents do the same. We expect our computer security to prevent attacks from others, EVEN WHEN THEY TRY, but for some reason our computers do not protect against hardware infection.
@Dagg: "The quantum noise from a diode is random and is used in random number generators. I don't know exactly what the intel engineers used, but basing it on the random quantum noise from a semi conductor junction would appear to be the easiest method."
Noise from a reverse-biased diode in breakdown is analog, not digital. Typically, the better it is, the tinier it is, and so harder to distinguish from amplifier noise, sampling, and a-to-d conversion. It is also not random, in that it has both an uneven statistical value distribution and long-term correlations between values. Indeed, the closer one looks, the worse the situation is. In theory it should work, but in practice requires deep understanding for serious results.
The investigation of a randomness device needs an unusual mindset, in the sense that simply claiming the sequence to be random is not enough, and statistical measures also are not enough. We know this because we could record any "random" sequence, and any test which would certify those results would be wrong when we re-use the sequence. But most designers will claim that their result "must" be random and stop, as they eventually must, simply to get on with life. For there is no natural end to this investigation. And the moment problems are found, and the device fixed, the investigation starts again.
Given a physically-random RNG device which passes basic tests, the only recourse is for someone other than the designers to invest extraordinary and unrewarding effort to expose pattern in the results. And if the results actually do cause change in the design, the only recourse is to do it all over again.
All of cryptography suffers from this. No cipher is proven secure in use. Generally speaking, all past ciphers have failed. Yet the only way to get a better cipher is to somehow, after years of work and as pure public service, find a problem in the current one. Nowadays, that would be the one approved by the US government, for why would insurance cover using anything else? And the end result would be yet another government-approved cipher.
The way around this is to not have a standard cipher, but instead have a standard cipher INTERFACE. Allow people to use whatever cipher they want. The more ciphers the better. Do not protect all knowledge in society with a single cipher!
Then require that 3 ciphers be used in sequence, each with an independent key, and one of the ciphers would be the current standard. This is multiciphering, with a result at least as strong as the standard cipher. Is "costly" multiciphering actually "needed"? Obviously it is, because we never should have trusted any single cipher, and certainly no longer can.
Note that all data ciphering should take a long random value or "nonce" (n-sub-once), encrypt it under that channel key, and then use the random value as a message key for the actual ciphering. By making the random value very long, we can reduce the impact of non-randomness from a randomness generation system we inherently cannot certify.
Realistically, though, ciphers start with plaintext and end with plaintext. It is unnecessary to "break" the cipher if one can access the plaintext, and malware bots do exactly that. Once again no tools exist for a normal computer which guarantee to detect a hiding bot. Obviously a prior-instrumented machine can see malware run and hide, but our problem is the normal machines we have, after the fact, and their problem is more about "infection" than malware running. While malware itself is encountered rarely, an infected machine runs malware on every session.
To address infection, we need to make the equipment not accept infection. That means no current hard drives (including USB flash and SSD), because they are easily written by malware. That also means no video card, because that BIOS could be infected. And it means re-flashing the motherboard and router BIOS periodically. But all of this could be avoided with proper hardware design, and the fact that it is not, is, frankly, suspicious. My guess is that certain organizations appreciate the fact that virtually every machine in the world can be infected, and that the users can do almost nothing about it.
"However, if there is any post processing of the random number..."
Because physical quantum noise is tiny, it must be detected by sensitive and error-prone physical processes. A common conceit is that randomness is the goal so "random" errors in detection can be ignored. That is false.
It is almost universal that the physics and detection mechanics combine to produce a non-flat or uneven statistical distribution from a physical RNG. If we want flat, post processing is not optional.
"There's nothing to suggest that even the NSA can readily break these algorithms, whose security ultimately relies on mathematical proofs on the difficulty of factoring the product of two very large prime numbers."
Sadly, there are no proofs which show that factoring is "hard" in a mathematical sense. A quick way to factor may yet be discovered. Perhaps it already has.
I find it useful to distinguish between: 1. "Encounter" (the user somehow comes upon malware), 2. "Insertion" (malware getting through outside defenses), 3. "Operation" (malware executing), and 4. "Infection" (malware entering persistent store to run in later sessions). Given our decades of experience, it seems unlikely that we can prevent the Encounter or Insertion, which of course will allow Operation for the remainder of that one session. However, it is within our power to reduce the probability of Insertion, and also to almost eliminate Infection.
If we were to somehow start with a clean system, and started a new session only to work with a particular site, and then ended that session by turning the equipment off, there is little likelihood of Encountering malware, and little time for it to work. Each session would start anew. But systems with hard-drives (and flashable BIOSes) tend to *accumulate* infection, so that, eventually, we expect those systems to *all* be infected. I strongly dispute the idea that it is possible to maintain security while having infection at OS or BIOS levels (or below). The problem is the bot(s), and the solution is to not have a bot.
Now, if we can gird our loins to somehow forego the seductive attractions of frequent persistent change in our system; if we can use a semi-static OS and BIOS (etc.), then every time we start a new session, we will be clean. By not saving infection, we can avoid bot-like malware, the worst of which which generally requires Infection.
Ideally, our OS and hardware designers would make our systems "difficult or impossible to infect," which they clearly have not done. Perhaps they have their own reasons. However, on our own, we can: 1. remove all hard drives (and flash drives) from systems intended to be online-secure, and 2. use hardware which contains only a single BIOS (etc.) which can be re-flashed (and, thus, re-secured) in one go. (It may not be possible to re-flash both the motherboard BIOS and (e.g.) a video BIOS without the other gaining control.)
We can work online by loading the OS into RAM from DVD, then removing the DVD and running from RAM (as in various Puppy Linux varieties). (In contrast, booting from a USB flash drive essentially returns to the dangerous writable boot drive concept. The mechanical aspects of DVD writing make malware writes slow and apparent, and then *impossible* with the DVD removed. A USB flash drive with a write-enable switch inevitably becomes as weak as a normal flash drive the instant the switch is flipped for update.)
Working in a thin-client environment does require some adaptation, but actually is much easier than one might think. For general browsing, I like thin-client Puppy just fine. For online banking, I do a full power-off reboot before and after that session. For watching Netflix, I use the insecure hard-drive-based (and probably infected) Win7 system in the living room, just like everyone else.
It is best to look each up on the addons.mozilla.org site; I use both. Certificate Patrol monitors and controls certificate changes, and announces changes that look funny. Getting a user to accept a certificate for the attacker is how MITM attacks penetrate SSL security.
Perspectives monitors IP address values across time and location. A range of different notaries each testify as to the IP they see for the SSL URL, which means an MITM attack must somehow intercept all connections for the URL, not just that going to the targeted user. Also, the IP values seem to be kept for about a month; to not be detected, the MITM attack must be first accepted, then kept in place for a long time. All of this raises the security bar in general, and probably exceeds what can be delivered in the usual coffee-shop MITM SSL attack.
The proposal is intended to address the particular problem of securing SSL from man-in-the-middle attacks where the attacker has obtained a trusted certificate. For this limited but important purpose, it is an alternative to the conventional Public Key Infrastructure of hierarchical trust via certificates. The approach seems similar to the Perspectives add-on for Firefox which has been available for a year or more.
@Turtle_Fan: "Let's face it the human tendency is always for a single sign-on approach. (Have just the one password, no matter how difficult or long). When all studies identify human factors as the no.1 vulnurability it's amazing that such systems have not adapted to accommodate this."
Take a look at LastPass dot com.
@The Nameless Mist: "What gets me is why the banks don't just issue two factor authentication devices ?"
Even 1-time 2-factor auth does not stop the main online banking threat -- bots. Sure, the bot does not have access to the external factor normally, but as soon as you type it in, it does, and then it can cut you off and do what it wants faster than you ever could.
2-factor just does not provide the security everybody assumes it does.
"Good encryption algorithms give you a guarantee "if you use this well-known algorithm, and keep the key secret, then it requires this much effort to break"."
Sadly, no well-known algorithm has any such guarantee, including the OTP. Belief in cryptographic strength is belief, not demonstrable fact. Math proofs almost never apply to real systems in practice.
There is an important distinction between malware somehow getting into the computer and executing, and malware being restarted on every session due to internal infection. Currently, most effort is directed at stopping malware from getting in, but malware does get in, and if it can infect, it can run in hundreds of future sessions. We need to stop the infection.
We need to prevent malware from modifying the operating system, boot data, and all other data which executes upon startup, including user apps. Currently, OS software tries to prevent this, and if that worked, we would have no problem, yet the problem persists. What we need is improved hardware to protect the boot process and data from being changed by malware.
Various schemes are possible, but in security, simple is king. The example that everybody loves to hate is the Linux LiveCD, but it is at least an existing, generally practical example of a system which is difficult or impossible to infect. Since over 99 percent of current malware is designed for Microsoft Windows, just using Linux is a big help, but that does not prevent infections from Linux malware (which does exist). It is the CD which protects against infection, but practical use does require updates.
As far as I know, of all the LiveCD distributions, only Puppy Linux supports updates by allowing the user to save new and changed files back to a multisession boot DVD as another session. I manually update immediately after booting, once every couple of weeks or so, on a DVD+RW. Various versions of the same file may exist on the DVD, but only the latest is loaded into RAM during booting. The system runs completely in RAM, and the DVD can be removed after boot.
A lot of things are not ideal about using a LiveCD. However, it is an actual practical example of serious malware protection (supporting browsing in Firefox with security add-ons), and the improvement over current systems is in the system hardware, not the usual add-on software or patches. Once we realize the harm our current hardware design has caused and look into fixes, a wide range of alternatives exist. Yet how many of us realize that our equipment needs to change?
In the US, I would ask for the FCC to type-accept all computation equipment, including routers and smart phones, and require it to be "difficult or impossible" to infect. Manufacturers should be required to provide tools to certify any particular installation of their system as uninfected, and thus ready for online commerce. A formal, Windows-like LiveCD from Microsoft would greatly assist online banking (even if an external DVD writer would be needed), but soon we will have to deal with those smartphones.
For more, find my page, articles and comments using: "Terry Ritter" malware
"The big advantage of the key-fob is (a) you can use it on multiple PCs, including untrustworthy ones, and (b) it is not connected to the internet and thus virtually immune to malware."
Certainly, one can use the key-fob anywhere one likes, but if it is used on a PC which has a bot (that would be the "untrustworthy ones"), the OTP will not protect the account credentials. The problem is not infection of the key-fob, the problem is a malware bot infection in the user computer or mobile device.
A bot is the real-time presence-by-communication of an attacker inside the computer. As such, the bot has many options, but the easiest is simply to wait until all authentication is done, and then access the opened account from the user's machine, while delaying the user with false data or errors. No authentication through the computer can stop this because no account can distinguish between valid commands ordered by the intended user and false commands ordered by the attacker, both coming from inside the user's own machine. And the bot can prevent user commands from getting through.
By itself, a key-fob is not a secure solution in the current environment. Not having a bot is the solution, and then your key-fob will work fine. Security thus requires some form of trusted hardware, such as a Linux LiveDVD boot.
"The problem with OTPs, not to put too fine a point on it, is that they can be a royal pain in the butt"
No, the real problem with OTP's is that they do not work. Neither OTP's nor external crypto dongles nor any authentication in any form can protect against an existing bot. Something like half of our computers do have bots, and that only counts what current tests can find.
The solution starts with not having a bot. Let Intel work on solving that.
We all need a password manager and then can easily manage hundreds of unique long, random passwords having serious strength. I have been happy with free LastPass.com, which encrypts locally and then saves the result in the clouds. There are versions for various browsers and OS's. There is a local "portable" version. The Firefox add-on saves an encrypted copy locally, for when the cloud is down (perhaps to access a router password). Passwords are easily accessed from different computers, either for normal work, or in an emergency. As in any password use, the local computer does need to be bot-free. I recommend booting Puppy Linux from DVD for online browsing.
"Where do I start ... "Windows", "
Windows, Mac, Linux, whatever.
Firefox has an add-in. Most browsers can use a bookmarklet.
There is a stand-alone "portable" version.
Everyone has my permission to look at the lastpass.com webpages for themselves.
"cloud",
The encrypted databases are kept both locally and in the cloud. That is the amazing new innovation called "off-site backup." (Although, with "automatic backup synchronization," it actually is pretty amazing.)
"current personal machine friendly" ...
Some of us really do go from machine to machine and need passwords. As suggested previously, we might just remember one good password and use that everywhere, which is dumb, dumb, dumb. Or we can use that password to open an encrypted database with lots of distinct and better passwords. The choice is just not that hard.
@Graham Bartlett
"Back in the real world, it's impractical for anyone with more than one PC...." Nonsense. I use LastPass.com on several Windows PC's and even more Linux "live" DVD's for banking. LastPass encrypts the little password database locally, then sends it to the cloud. When I change machines, it brings the encrypted database down from the cloud, and adds any new entries to the current machine. Easy peasy.
"it's *way* too much hassle for your average civilian." Nonsense. My wife claims to be an "average civilian," and she uses LastPass. I just needed to get her started.
"and it's not secure enough for the tinfoil-hatters." The issue is web security: banking, buying, email, docs, so on. LastPass encrypts passwords locally, and nobody else has the master key. (Do not forget that key.) LastPass also offers little text "Secure Notes" storage for private details beyond the usual password.
"...having one good one is a damn sight better security than the alternatives of either writing down your passwords or using multiple weak passwords." So, just because it is slightly easier to use the same password everywhere (and then be unable to change it) than to learn to use LastPass, that makes it a good idea?
If Schneier really thinks that "you should have one good password, and use it everywhere," he is an idiot, and you can tell him I said so. The solution is to use a password manager, with a different long, random password for every device, site and account. We might even use his own design, Password Safe. (Nowadays, I use LastPass.com)
from 2003: http://www.schneier.com/crypto-gram-0307.html#7
"Many computer users today have to keep track of dozens of passwords: for network accounts, online services, premium Web sites. Some write their passwords on a piece of paper, leaving their accounts vulnerable to thieves or in-house snoops. Others choose the same password for different applications, which makes life easy for intruders of all kinds. Password Safe is a free Windows utility (originally developed at Counterpane Labs) that allows users to keep their passwords securely encrypted on their computers. A single Safe Combination -- just one thing to remember -- unlocks them all."
Certainly scanners cannot possibly detect all malware, because they depend upon each malware previously having been found in some other way so their signatures could be added to the scanning dataset. New ("zero day") or targeted malware will not be found.
However, it *is* possible to find *every* malware infection: Just check every OS file used when booting and see if it has been changed. That cannot be done effectively within the OS, but can be done externally with some sort of manufacturer provided "Live" CD. It also does require the OS to be designed for security, by eliminating or otherwise controlling every dynamic file which could load malware at startup.
Although we presently do not know how to control infection through the browser, we *do* know how to *prevent* infection. By "infection" we mean that malware has changed the contents of OS files or boot files so as to re-install itself on every reboot. No form of software or OS protection (e.g., read / write or user / root permissions) can prevent infection when the OS itself has been subverted. However, new hard drive specifications *could* provide *hardware* *protection* for boot files and data, allowing only owner-authorized changes. Until then, widespread use of DVD booting could greatly reduce infection.
The first step in preventing infection is to prevent malware from gaining control in the first place. To the extent that most malware comes upon users essentially at random, malware generally assumes the presence of common software. Since over 90 percent of browsing occurs in Windows, the most important part of avoiding malware is to not use Windows on line.
Personally, I boot Puppy Linux from DVD+RW and run Firefox with extensive security add-ons.
To secure a laptop, remove the hard drive (which then cannot be exposed or infected), and boot Puppy Linux from DVD+RW. Puppy loads into RAM so the DVD can be removed in use.
I have some articles analyzing malware and describing the configuration and use of Puppy Linux for security, starting at
http://www.ciphersbyritter.com/COMPSEC/COMPSEC.HTM
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
