> "complete enabling"
> muh encryption
> rdrand enabled
and general hardware is backdoored thread
> Cavium is a fabless semiconductor company based in San Jose, California specializing in ARM-based and MIPS-based network, video and security processors and SoCs.
> Cavium offers processor and board level products targeting routers, switches, appliances, storage and servers.
# disable RDRAND in linux
If your /proc/cpuinfo has rdrand, do the following:
1. Stop the kernel from using rdrand
# add "nordrand" to your kernel cmdline
# edit /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT.. add "nordrand"
2. Stop openssl from using rdrand
# to make system-wide, add to /etc/environment
3. Reboot and check results.
# grep rdrand /proc/cpuinfo
# openssl engine -t
By default openssl will use *pure* RDRAND as its random number generator! openssl does not use /dev/random, /dev/urandom, or any kernel provided generator. Patching openssl's md_rand.c is required to fix this.
A RTL DVB dongle using https://github.com/pwarren/rtl-entropy and rngd is much better than a tainted rdrand.
>Linus Torvalds dismissed concerns about the use of RdRand in the Linux kernel, and pointed out that it is not used as the only source of entropy for /dev/random, but rather used to improve the entropy by combining the values received from RdRand with other sources of randomness. However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator becomes completely insecure when a backdoor is introduced into the RdRand instruction. This backdoor can be inserted, for example, by means of a microcode update. Taylor's proof-of-concept implementation works on an unmodified Linux kernel.
You dumb niggers do realize OSes don't use RDRAND directly right? It's one of several things that affect the outcome it's not the only one. Disabling RDRAND isn't going to help your security much if at all.
That's what I'm thinking. OpenSSL is a real piece of work. The devs basically rewrote a lot of basic functionality just for obsolete platforms but here they have a platform specific feature that they hardcoded for some reason.
You know the answer. Anyways, you can recompile openssl with an alternate ssleay_rand_bytes() that will actually use OS randomness. Or ditch it entirely and use https://www.libressl.org (preferred).
I really wish the NSA would work on making computers more secure rather than less secure.
I mean all the hardware they backdoor isn't used by their targets anyway.
It's literally just to spy on americans.
>government agency doing something publicly constructive
Why is the NSA so keen on destroying the US tech industry? The Snowden leaks are blamed for making US tech companies lose $30 billion because of everyone dropping contracts and refusing to buy backdoored shit.
The first line is referring to Skype.
The second one is referring to backdoors in Cavium Nitrox chipsets (used in Citrix and F5) and Broadcom (Niagara, BCM5823 - used with Cisco ASA) cryptographic accelerator cards.
Having seen AMT in action my personal opinion is that every Intel based computer can be fully accessed out-of-band. Regardless of which OS and SSL you think is trustworthy, it's not.. The packets AMT uses are not visible when using tcpdump for example - check for your self. It's really that scary and automatically building mesh networks which pierce any firewall near it.
From the research I have done, I have found that Intel's Bull Mountain TRNG (RDRAND/RDSEED) is not backdoored en masse. (Although, the dual ring oscillator design is not as proof as I would like to illumination attacks, I was not been able to pull one off in the lab without crashing the chip, even decapped, let alone through a PC case.) The design used in AMD's Zen is also sound, or at least was last time I saw it (I have not seen any hardware tape-out yet).
However, it is sensible to treat all of those as normal hardware random sources, and to put them through a software CSPRNG (rather than simply XORing them in). More recent releases of the linux kernel and OpenSSL do in fact do this properly. When this is handled correctly, as long as at least one sound entropy source is available, it is impractical to harm the state of the CSPRNG: rapid partial second-preimage attacks which there is no chip (or microcode) area available for would be needed.
I believe GCHQ (working with NSA) have intercepted some packages and performed targeted attacks, swapping chips with ones backdoored by carefully tampering with the doping of the silicon in the AES whitener of the CSPRNG, forcing most of the bits to 0 (reducing the entropy to about 40 bits). Sample backdoored chips were I understand acquired from an embassy of a South American country.
This avenue of attack was independently reconstructed by civilian researchers. The tamper is not visible in optical mask analysis, but the doping is different in that area than a control Ivy Bridge chip of the same model; the resulting circuit does not compute AES correctly. Electrical analysis reveals the tamper. This exact attack would not work with Broadwell and onward's RDSEED (as the whitener is not used) - a Haswell test chip attacked in this manner failed its self-check and would not POST. However, given such advanced unrestricted physical access, all bets are off in a highly-targeted attack against hardware like that.
tldr this really only affects people who run an improper OS OS X or windows and actually trust the built-in disk encryption (often based on outdated, substandard "good enough for you, civillian" algorithms anyways)
Why can't they just fuck off.
I'm doing fuck all on my computer that's considered illegal save for torrenting movies.
That's because they never arrive at the CPU. Most modern Intel CPU designs use an internal Management Engine (ME) for this kind of support, which is impressively undocumented. It uses an embedded RISC ARCompact core, and runs the commercial ThreadX RTOS (the Raspberry Pi's stock firmware uses the same RTOS, for reference).
The software running on it is complex, and the modern stuff is actually embedded Java. Botnet would, actually, be an accurate description (as would remote management, which is what it's ostensibly for).
I have not performed a deep enough analysis to determine how vulnerable it is or if there are any exploitable bugs or backdoors, but it is an interesting area for future research - and an overwhelmingly tempting target for any intelligence agency.
because the world is in an absurd state, like a combination of 1984 and brave new world.
all freedoms are taken away slowly and more spying is added everywhere while using security as an excuse.
meanwhile the masses are kept busy with bread, circus, and endless distractions so nobody really cares that they've given up their privacy completely.
Windows 10.0.1511.10586 actually added the superior XTS-AES-128 mode as the new default for Bitlocker. Finally.
If you have Windows 10 Pro, and don't choose to upload the recovery key to Microsoft, it's the best solution you can get on the Windows OS for disk encryption, dealing with power management better than TrueCrypt (and forks), and of course supports UEFI (which TC doesn't).
That brings it up to speed with Linux's dm-crypt defaults. It's very good, but be aware of XTS's limitations: never let the attacker write to your raw disk, or (equivalent) store the volume on the network. You need authenticated encryption (AEAD, or Encrypt-then-MAC) to cope with that threat model, but that demands overhead, and unfortunately quite a lot of software goes apeshit with logical sector sizes which differ from physical sector sizes, which is why no disk encryption software I've ever seen does it.
I've never been able to stop laughing at Mac security long enough to do a proper analysis, so you'd have to ask someone else about that. iOS security, on the other hand, is actually pretty good (at least, better than Android).
yay for being a poorfag with old hardware
You're welcome. We're not all neckbeardy shitposters. (Some of us don't have beards.)
The lesson to take away here is just because it's usually fine doesn't mean you should just blindly trust it.
I'm sorry I can't share all the juicy details, but NDAs are NDAs, even though I'm retired now. The civilian paper (Stealthy Dopant-Level Hardware Trojans) was presented at CHES 2013 by Becker, et al. At that time, they had not yet found one in the wild, but they pretty much nailed the technique I think was used.
So contrary to what logic suggests, using /dev/urandom instead of hardware randomizer is a better practice because even if rdrand """"""""fails""""""" to deliver what it's supposed to do urandom will introduce at least SOME degree of entropy?
Yes. Randomness cannot be worsened by adding in "bad randomness" into the pool. So RDRAND can *only* increase the entropy. Even if RDRAND would just keep providing zeroes to the pool, the entropy would at least be as good as without RDRAND.
Some people believe the NSA or another government agency has forced Intel or other companies to weaken their PRNG hardware to make it easier to crack encryption software. It's hard to really prove that but generally software doesn't take output from only one source of entropy.
Daily reminder that Theo de Raadt is always right.
Open source doesn't matter as soon as hardware is involved. Just read >>52276752, even if the hardware itself is 100% spy-free, apparently the NSA could still tamper with it to make it less secure without you noticing.
Intel remote management allows you to access some kind of management panel for the machine, even when it is turned off.
Refer to https://en.wikipedia.org/wiki/Intel_Active_Management_Technology
Intel AMT is part of Intel vPro.
It primarily displays information, but I believe you can also flash the BIOS/UEFI from there.
Security researches have found it to be rather insecure, I think it even had a pre-authentication vulnerability.
A vulnerability might allow an attacker to gain full control over the machine (without the user being able to ever notice it.)