> "complete enabling"
> muh encryption
> rdrand enabled
and general hardware is backdoored thread
>>52270146
Are they refering to Amd and Intel or other TPM devices?
Cavium, Inc.
> 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.
https://en.wikipedia.org/wiki/Cavium
# 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"
sudo update-grub
2. Stop openssl from using rdrand
# to make system-wide, add to /etc/environment
OPENSSL_ia32cap "~0x4000000000000000"
3. Reboot and check results.
# grep rdrand /proc/cpuinfo
# openssl engine -t
>>52270305
everything.
>>52270795
>targeting
I wonder what the internet will be like in 2020
>>52270146
Is it confirmed that they're talking about RdRand and Cavium thingy?
>>52271459
No, only suspected possibilities.
>>52270989
RDRAND might be a good thing to disable, but it'd be better still to use RDRAND's output as a seed for another RNG.
>>52271975
It is a good idea. I think FreeBSD does that, actually.
>>52271975
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.[19][20] 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.[21][22][23]
kek
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.
>>52272370
>don't use RDRAND directly
OpenSSL does. And any application linked to it that asks for random bytes will get them unadulterated directly from rdrand.
>>52272430
Why on earth wouldn't OpenSSL rely on the OS to get randomness?
>>52272510
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.
>>52272430
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).
>>52272646
How can I replace OpenSSL with LibreSSL in Debian? I am a massive noob.
>>52272282
Linus was mightily butthurt when he was called out on RDRAND. "We know what we're doing!"
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.
>>52273664
>government agency doing something publicly constructive
Don't buy Americatech
>>52273664
Nigeria used to be the homeland of Internet bad guys
Now it's USA
>>52273775
>internet bad guys
>a bunch of niggers sending chain scam emails all day long
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.
>>52275076
Thank you Snowden
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.
>>52270989
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.
>tfw I'm canadian and the american government is spying on me
>literally can't do anything
get your shit together americucks
>>52276752
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 /g/.
Why can't they just fuck off.
I'm doing fuck all on my computer that's considered illegal save for torrenting movies.
>>52276627
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.
>>52276752
Thank you for sharing these findings.
>>52276770
You're probably buying the same hardware so... good luck.
>>52276872
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.
>>52276806
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
i guess
>>52276981
Also yay for living in a third world country and can't afford new hardware.
>>52276981
so what's the oldest hardware affected by this?
>>52276888
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.
>>52270989
>>52271975
>>52272128
>>52272282
>>52272370
>>52272430
>>52272510
>>52276752
hol up
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?
>>52277133
according to the wiki rdrand was introduced with ivy bridge arch.
So if we pretend for a moment that every doubt about rdrand is true we're talking 2012 and up
>>52277256
didn't sandy bridge also have some sort of remote kill switch?
feels good to be using westmere from 2010
>>52277224
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.
>>52277224
>>52277606
Note though, that's the theory and how it SHOULD be. Specific implementations of an RNG can still fuck this up.
>>52277379
sandy bridge and newer have intel remote code execution™.
Though I think they call it intel remote management™.
>>52277219
so they changed the doping of a couple transistors? Do they have facilities to do that themselves or did they tell intel to do it?
>>52272510
The NSA probably contributed that part of the code
>>52277693
Is this real or Bait?
And generally, please explain this whole thing to me. How does something that generates randomness related to spying on your computer?
>>52278022
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.
int randomNumber() {
return 4; //determined randomly by dice roll
}
>>52278329
*Theo the Rat
ftfy
Why doesn't somebody just make a completely open source hardware/software dongle that can generate random numbers?
>>52278420
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.
>>52278022
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.)
