- cypherpunks@lists.ogf.org

Re: [cryptography] Which encryption chips are compromised?
by coderman 12 Dec '13

12 Dec '13

On Wed, Dec 11, 2013 at 6:28 PM, Steve Weis <steveweis(a)gmail.com> wrote: > ... > Ivy Bridge processors are general purpose x86 CPUs. It doesn't make sense to > me to refer to it as an "encryption chip" for "web encryption devices". "used in Virtual Private Network" == PPTP,IPsec,OpenVPN,etc. "Web encryption devices" == in my interpretation, this is any targeted hardware with the vulnerable chip. it could be a tablet, a desktop, and rack mount server... any of these platforms could speak VPN or Web crypto. TAO/SCS do like to get into the switches though ;) > Do > you know of products using IVB processors for SSL offloading or in VPN > appliances? mostly "cloud infrastructure", "software defined data center", and the like: http://www.routeranalysis.com/the-vyatta-cloud-router-story/ http://www.routeranalysis.com/etsi-network-function-virtualization-working-… > To me, the redacted document sounds like it's referring to a security > processor used for SSL offloading. For example, something like a Cavium > Nitrox (which I'm not implying is the subject of the document). back in the day, Sun got tired of the (relatively) slow performance and latency of crypto offloading via bus and simply threw it into the core. you were still offloading crypto, but within the CPU. also note that endpoint compromises sufficient to decrypt VPN or secure web traffic is already present in TAO/CNE's tasking. this effort [CCP_00009] may focus on VPN concentrator / secure web proxy deployments specifically to handle the RDRAND lookup per their private starting counter. previous back doors have also used entropy leakage sufficient to bring a brute force attack into reasonable effort, while still denying third parties a class break of the entropy / keys used. this type of key space search is not done on the ground with portable CNE but instead back at SCS... on a related tangent, the lack of additional disclosures is quite frustrating. this entire conversation would be resolved in a glance if $the_snowden_gatekeepers were acting in the public interest. :/ best regards,

1 0

Android IMSI Catcher detection
by Matej Kovacic 12 Dec '13

12 Dec '13

More info here: http://secupwn.github.io/Android-IMSI-Catcher-Detector/ P. S. Developers needed. :-) Regards, M.

8 16

Re: [cryptography] Which encryption chips are compromised?
by coderman 12 Dec '13

12 Dec '13

On Tue, Dec 10, 2013 at 4:11 PM, <dan(a)geer.org> wrote: > > * (TS//SI//REL TO USA, FVEY) Complete enabling for [XXXXXX] > > encryption chips used in Virtual Private Network and Web encryption > > devices. [CCP_00009]. > > For this to be an explicit line item in that document, it > has to be special. unredacted: https://peertech.org/dist/nsa-cpp-goals-FY2013-unredact.png "Intel Ivy Bridge"

1 1

Fwd: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say
by coderman 11 Dec '13

11 Dec '13

---------- Forwarded message ---------- From: coderman <coderman(a)gmail.com> Date: Wed, Dec 11, 2013 at 12:06 AM Subject: Re: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say To: zs-p2p(a)zerostate.is On Tue, Dec 10, 2013 at 3:57 PM, Bill Cox <waywardgeek(a)gmail.com> wrote: > ... > So, I'm going to modify it a bit to use the resistors available on my chip > and reduce the caps, fix the supply sensitivity, and I think I can run 16 of > these things in parallel at 100-200MHz on the tiny .35u CMOS chip I'm > designing. I'll spit out the raw waveforms from the inverters, buffered > once, through 16 "analog" pins, so there wont be any fear (hopefully) that > I'm cooking the data on-chip, before you can see it, and I'll open-source > the schematics. If there's a circuit that can consume all 1.6Gbit/sec of > this raw data, have fun with it! raw samples at 1.6Gb/s would be useful infrequently[0]; raw samples from a trusted device extremely useful at any bitrate! what is "my chip" and how can we find out more / support your efforts? best regards, 0. to date i have only maxed out 400Mb/s raw VIA Padlock sources for SSD FDE initialization and constructed experiments in temporal key rolling. it is however common to regularly consume on the order of 10Mb/s on a busy server, generating many keys, using crypto happy software, etc. (this is why every processor, every embedded device should have a physical entropy source, with access to raw samples. still waiting...)

1 0

Fwd: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say
by coderman 11 Dec '13

11 Dec '13

---------- Forwarded message ---------- From: Bill Cox <waywardgeek(a)gmail.com> Date: Tue, Dec 10, 2013 at 3:57 PM Subject: Re: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say To: cryptography(a)metzdowd.com I have to take back my criticism of Intel's RNG. I got my sims working for a version of their architecture in .35u CMOS, and it's simply better than my "Infinite Noise Multiplier". It's probably the best true random noise generator ever. I still don't like how their schematic is seems highly sensitive to supply noise, but we don't know what the actual circuit looks like. Intel hasn't told us. So, I'm going to modify it a bit to use the resistors available on my chip and reduce the caps, fix the supply sensitivity, and I think I can run 16 of these things in parallel at 100-200MHz on the tiny .35u CMOS chip I'm designing. I'll spit out the raw waveforms from the inverters, buffered once, through 16 "analog" pins, so there wont be any fear (hopefully) that I'm cooking the data on-chip, before you can see it, and I'll open-source the schematics. If there's a circuit that can consume all 1.6Gbit/sec of this raw data, have fun with it! On the digital side, I'll XOR bits together to get the bandwidth down to something reasonable, which I can send over USB, and provide a simple Linux driver. This thing will definitely put out RF, but since I'm making the raw data available at the pins, should I care? By the way, this is just a for-fun project at work. I get to do a free chip design :-)

1 0

Fwd: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say
by coderman 11 Dec '13

11 Dec '13

---------- Forwarded message ---------- From: Bill Cox <waywardgeek(a)gmail.com> Date: Tue, Dec 10, 2013 at 1:26 PM Subject: Re: [zs-p2p] [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say To: cryptography(a)metzdowd.com I think there may be weaknesses in Intel's hardware RNG. I took a good look at Intel's hardware random number generator source. There's a paper analyzing it here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf The basic idea is that back-to-back inverters, when powered on, flip one way or the other randomly, sort of like DRAM memory when our computer's power on. By powering on a single pair of back-to-back inverters over and over, they can generate a random bit per cycle, at about 3 Giga-bits/second, which is amazing! Here's my concerns about the the paper: - I saw no mathematical analysis of how much noise exists in the system and how strongly it will influence the result each cycle. There were generalities about how the noise could cause the output to be random, but no numbers at all. - There is an assumption that the capacitors are charged/discharged by 10% of the standard deviation of the noise. I saw no justification for this. It seems they simply assumed best case. - The paper is about as objective as a mother talking about her children. For example: "Overall, the Ivy Bridge RNG is a robust design with a large margin of safety that ensures good random data is generated even if the ES is not operating as well as predicted." Based on what? - I am not convinced they have the right model for the entropy source. They add noise to the bias on the capacitors, and compare that to 0 to determine the next output bit in their model. I think the main source of noise may be the randomness in number of electrons added/subtracted each cycle, and that the back-to-back inverters in the absence of other noise may be acting almost as an ideal comparator. However, if this were the case, even if there were 10% noise in the number of electrons, there would be considerable correlation between bits. I also have questions about the design itself. My main concern is that noise on the VDD rail could easily determine the output. For example, if the transistors are mismatched, which of course they will be, and the bias is set exactly right on the caps so there's a 50-50 chance of a 0 or 1, and suddenly VDD drops 10% due to a rising edge of the the main system clock, then the inverter with higher gate thresholds will become weak faster than the other one, thus determining which one wins. Since this circuit runs asynchronously from the main system clock, I could easily see the 3MHz system clock phase relative to the entropy generator clock determining most of the results from the entropy source, while looking fairly random. Any weakness in the raw random data stream is hidden from us by the AES encryption done as a post-process. I simulated back-to-back inverters in my .35u low power CMOS process in SPICE to see if I could figure out how to make a practical circuit using Intel's topology. If it works, it would be fantastic. I think I can get rid of most of the supply noise issues. I had a similar problem in my "Infinite Noise Multiplier", so I switched to powering the circuit with nothing but large W and L constant current sources, and using the range from 0V to Vref, rather than 0V to VDD, because Vref is stable relative to AVSS. However, I wasn't able to get enough noise to make Intel's ciruit work, though that may be due to limitations in the SPICE simulator. Has anyone else had success using Intel's RNG topology?

1 0

Fwd: [cryptography] Which encryption chips are compromised?
by coderman 11 Dec '13

11 Dec '13

---------- Forwarded message ---------- From: coderman <coderman(a)gmail.com> Date: Tue, Dec 10, 2013 at 7:12 PM Subject: Re: [cryptography] Which encryption chips are compromised? On Tue, Dec 10, 2013 at 4:11 PM, <dan(a)geer.org> wrote: > ... > For this to be an explicit line item in that document, it > has to be special. The two classes of "special" that occur > to me are (1) XXXXXX has a near monopoly (like Broadcom > does in its sector) or (2) XXXXXX is uniquely vulnerable to > blackmail (a merchant with an export control problem, say). you ask interesting questions Dan, and draw useful conclusions :) some items to note: - is this DUAL_EC_DRNG? don't think so. deadline is FY 2013. - is this DUAL_EC_DRNG? the market for closed source, proprietary crypto solutions is small (and growing smaller, :( - is this XSTORE? it's been a while. but never should have been used directly. see mtrngd with MSR bits set no whitening, max sample, max freq. into mix + conservative estimate before /dev/random write. > But in related news: > > Engineers abandon encryption chips after Snowden leaks > http://rt.com/usa/snowden-leak-rng-randomness-019/ some cryptographers and cypherpunks have become despondent or dejected or demoralized by these events. i see a larger picture: never before have so many been doing crypto less wrong! ;P

1 0

Open phones for privacy/anonymity applications, Guardian
by grarpamp 10 Dec '13

10 Dec '13

A few links... http://neo900.org/ http://projects.goldelico.com/p/gta04-main/ https://jolla.com/ http://www.fairphone.com/ http://hardware.slashdot.org/story/13/11/02/1637236/openphoenux-neo900-bill… More interesting platforms for even Guardian or other OS than any Nexus 5 or alike hardware, no? https://guardianproject.info/hardware/ http://unrevoked.com/rootwiki/doku.php/public/root_friendly http://wiki.cyanogenmod.org/w/Devices

8 10

good clocks (not using GPS) and multi-channel hw [was: sidebands of great justice]
by coderman 09 Dec '13

09 Dec '13

On Thu, Nov 7, 2013 at 11:32 PM, coderman <coderman(a)gmail.com> wrote: > ... > SDR MIMO kit leaves much to be desired, however. let me clarify: the hardware available for SDR MIMO development leaves much to be desired. ... the blocks and implementations for OFDM coding in software are OK :) USRP N2X0 can do it, other setups require external reference clock with high fidelity. any recommendations for non-GPS clocks performing at 50-100ppb or better?

3 4

Re: EM-nature (was: infra-org)
by Bill Stewart 09 Dec '13

09 Dec '13

>JYA wrote: > > The celebrated EM components of TEMPEST are commonly > > used as subterfuges, ruses and ploys to divert attention from > > the non-EM -- which an almost limitless number of animals and > > other creatures use for SIGINT and COMINT... Back in the 80s I ran a TEMPEST-shielded computer room, with a VAX 11/780 and later some Sun-2 workstations, doing studies for the government that they didn't want Commie Spies listening to. The shielding was basically plywood with sheet metal on both sides, with special metal joints in between them and on the corners, packed with wire mesh in the joints to plug any extra leaks, making a nice big Faraday cage. The air vents were metal grates an inch or two deep with zig-zaggy airflow paths, and our data connections used fiber optics going through waveguide holes that were about 3" long and 1/8" diameter. Power feeds used big inductive low-pass filters. We measured the RF-tightness using meters that ran at 450 MHz, trying to keep things 120dB tight. You had one person carry a transmitter on one side of the wall, another person a reader on the other side. One experiment we'd occasionally do was to stick a wire through the fiber waveguides, and if you got more than halfway through, that was enough for 450MHz to leak out. I'm not sure what frequencies we *really* needed to protect against, but the Vax ran at something like 10 MHz, so 450MHz was way overkill for any harmonics that might happen. What occurred to me recently was that 10 MHz computers may have been state of the art for the mid-80s, but that was a lot of iterations of Moore's Law ago, and I doubt the technology of the time is much use for current 2-3 GHz laptops. The main Faraday cage should be fine, plus or minus a bit of extra copper tape to plug minor leaks, but all the air vents are going to be awfully leaky at those frequencies. Any idea what people use today?

2 1