QuickPath/UltraPath link encryption?

By: Aaron Spink (aaronspink.delete@this.notearthlink.et), December 12, 2018 2:22 pm
Room: Moderated Discussions
Jeff S. (fakity.delete@this.fake.com) on December 12, 2018 9:03 am wrote:
> The approach we were most wondering about is a compromised processor package with a custom substrate and QPI-intercepting
> ASIC being slipped into the supply chain or into a host directly. Functionally, it would need to do little other
> than snoops traffic from PRM and perform unsolicited DMA/uncached echo writes of the contents to a non-protected
> range for a compromised OS/HV to exfiltrate. Since the CBox and BBox/Home Agent supposedly explicitly disallow
> DMA transfers within the PRM range, actively spoofing requests and intercepting fills that comply with the full
> undocumented coherence protocol (including migratory forwarding) would probably be nightmarish and necessitate
> just waiting for an enclave homed on one socket to be instantiated on the other.
>
> Protocol-level defenses would require both stream encryption and cryptographic authentication of endpoints
> (which does still feel like overkill at this point in time), but honestly we don't have a good picture at
> all of the complexities of the overall reverse engineering and attack creation even in the unencrypted case.
> If there are simple design reasons why it would be intractable or infeasible to make a co-packaged ASIC that
> could snoop and inject QPI traffic, I would really appreciate some basic understanding of them.
>
> Some of our IP is valuable enough that even a $100M attack would pay off, but risk is considered diminished
> more by the fact that adversaries would basically start needing State support just to conceal money trails,
> and they would not want to need to pay off their investment quickly enough as to be conspicuous.
>
The attack you are envisioning would require either Intel themselves to want to attack you (and be willing to pay some serious money and engineering resources on it) or a large state actor (in which case you are basically fubar anyways as they will also be able to compromise human sources). Outside of those two, its not really going to be viable. It would require someone to slip in a rather large and complex manufacturing change along with designing an ASIC using a largely undocumented protocol and designing a complex MCM package that has no differences from the standard commercial package.

> My knowledge of IF link scrambling is secondhand from someone who asked me about some unexpected BIOS
> options of a Threadripper (that I have not verified), so you may well be correct there. Plus I thought
> I had heard AMD had its AES engines in the memory controllers and not IFOP/IFIS blocks.
>
Scrambling is a method that uses probabilistic methods to create required bit disparities to enable local source synchronous clock assistance of the receive circuits for ultra high speed signalling. Generally this takes the form of a deterministic LFSR that is XOR'd with the link data at both ends. This is possible on circuits that share effectively some sort of common clocking and design. The alternative is to utilize expansion coding such as 8b/10b, 64b/66b, or 128b/130b encoding which intrinsically maintains bit disparity. These encodings introduce delays and limit min phit sizing (physical unit of transfers) which can result in even more delays (need all the line bits before you can decode the phit which in the case of 128b/130b and multi-byte interfaces can result in rather large phits and large delays, these aren't much of an issue for an external network interface but present significant timing delays/latencies for interconnection networks). As such for interconnection networks, scrambling is preferred. These scrambling systems are capable of being effectively turned off for debug purposes as the primary effect of the disparity systems is reduction of BER of the high speed signals and there are cases in testing/bring up where you don't want the additional complexity.


> Agreed, but the language for this one section sounded substantially more concrete
> than the typical "one embodiment of X would blah blah", so I thought there
> might actually be some protocol extension spec floating around.
>
I've submitted patents for things that were very concrete but never actually implemented. AFAIK, no one actually does link level encryption in the field currently for a variety of reasons (not the least of which is that end to end is much simpler and robust).

> > The reality is that the hardware interfaces are the least of your problems.
> > The software interfaces will be the go to way to get into anything.
>
> Most of the core SGX design seems quite solid (Foreshadow/L1TF sidechannel attacks notwithstanding),
> which theoretically sidesteps all software based exfiltration concerns from untrusted hosts.
>

Still ,IIRC, both SGX and AMDs memory encryption have been pierced. The problem is very rarely in the actual hardware side but in the software interface/functionality.

The simple rule is that if you really really really care about security, you only run your software on machines that you control software and hardware access to. Breach that and it gets super messy. Not even getting into nefarious firmware and ghosted host VMs.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
QuickPath/UltraPath link encryption?Jeff S.2018/12/11 02:16 PM
  QuickPath/UltraPath link encryption?Anon2018/12/11 05:09 PM
    QuickPath/UltraPath link encryption?Jeff S.2018/12/11 08:54 PM
      QuickPath/UltraPath link encryption?Anon2018/12/12 04:18 AM
      QuickPath/UltraPath link encryption?Aaron Spink2018/12/12 07:02 AM
        QuickPath/UltraPath link encryption?Jeff S.2018/12/12 10:03 AM
          QuickPath/UltraPath link encryption?Aaron Spink2018/12/12 02:22 PM
            QuickPath/UltraPath link encryption?Jeff S.2018/12/12 04:04 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell green?