For me the most prominent problem was that Corsair ValueSelect RAM was causing system instability, despite being on Intel's list of verified memory. This was easily fixed by changing to a different brand. My thread about it is here: NUC6i3SYH Random freezes
The other problems I had were fixed with BIOS update 0033. Using Arch Linux.
Well, mine ran fine for 6 hours. Evo 850 with HyperX 4ibk 2*8GB. I updated the BIOS to 0033, which disabled M2 under PCI settings. But I didn't know that. So I performed a BIOS recovery back to 0028. Which was successful according to the system. But after the next boot it kept looping without any output.
So, just as a precautionary warning. Don't downgrade 0033 back using BIOS recovery method. It will may brick your NUC6i3.
Thanks a lot for putting this together. My main issue is that playing 3D iso using Power DVD or even Stereoscopic player, yields artifacts in 3D like described very accurately in this post:
"Using PowerDVD 15 I am seeing inconsistent playback of 3D blu ray. When I start a 3D movie (TV is a Vizio M801D-A3; 1080p/24Hz; frame-packing), the image may distort frequently and cause an image that appears to almost look like its viewed underwater. Depth of the image is also incorrect for seemingly random parts of the image. If I then pause the movie for a few seconds, or back up to the beginning of the chapter, the issue so far resolves itself, but sometimes it takes a few tries to do so."
I'm at my wits end and it seems others have tried to no avail and Intel has not really even bothered to care about resolving this issue through all the gnereations of the Intel NUC, including Skylake.
How did you do the downgrade? You have to open the case and remove a jumper. I did this this morning, because of lots of other issues with 0033 and the downgrade worked perfectly. If -- while doing the downgrade -- you don't get any video output, just wait. If the power led is blinking the firmware is being flashed. In my case I only got video output once the flashing was (almost) finished.
I followed the procedure. Not my first time. System told me flash was finished (I saw the whole procedure on screen). Power off, replace jumper, then reboot. So I did. Now it doesn't do anything. Power on, the fan blows for 30 seconds or so (no LED). After that it reboots and keeps on looping.
Repeating BIOS recovery mode doesn't work anymore. So I filed a service request. See my post:
So with the help and suggestions from Intel CC I got it working again.
The NUC refused to perform a BIOS downgrade using BIOS recovery method. I removed the SSD (850 Evo) and tried 0028 and 0033. Those didn't work (trust me I tried several times and left the NUC for at least 30 minutes). The NUC did absolutely nothing.
Then I tried 0024 without the SSD installed. The screen went on and the BIOS recovery worked. But my NUC still would not boot to BIOS. So I tried the BIOS recovery option again, but this time I used 0033. I figured 0024 worked, why not 0033. Flashed 0033 using BIOS recovery, placed the SSD back and voilá went straight to BIOS.
My NUC is up and running again!
If the NUC won't boot, nor give any output... Remove SSD and try 0024. For some reason only 0024 worked for me. The other two would not let my system boot. Screen would not lit, nothing!!
Skylake NUC System Hardening: Intel drops TPM header in Skylake NUC line because Skylake microprocessor has an embedded TPM 2.0 coprocessor. Intel decided not initialize it in its Visual BIOS program resulting in security threat to the device and to your network. See thread: SKYLAKE NUC - PTT Platform Trust Technology - AES Encryption Coprocessor - TPM 2.0 Capabilities - System Hardening - When will Intel Visual BIOS be configured to allow for NUC system security and hardening?
Please elaborate on how exactly not having a TPM is a "security threat to the device and network".
TPM has been pushed by vendors (including Intel, AFAIK) also to be able to do even more tamper proof digital restrictions management and software license management. E.g. a BlueRay software player may use a TPM to store its decryption keys, making it impossible to extract them for "alternative" use e.g. by free open-source software to decrypt and play back BlueRay on open source systems such as Linux. I, for one, am fine with not having a TPM available to the OS.
How a TPM *in practice* does anything useful is completely beyond me. So, please, elaborate. State the OS you're using and how that OS is using that TPM to protect your "device and network".
I would also like to know how any practical attack -- which so far reality has shown to come mainly from the state and its three-letter agencies -- is averted by a TPM. I consider code signing snake-oil. A powerful attacker (said three-letter agencies, e.g.) may have the keys needed to sign its malicious code.
Besides all that, I'm not sure the Skylake TPM is not used for its primary job: Ensure the firmware is not modified. I.e. only boot the firmware if it has not been tampered with. The TPM does not need to be visible to the OS for this job. It is only needed to be visible to do the other functions (like DRM). Once the firmware is booted it's the firmware's job to extend the trust, e.g. by booting only signed boot-loader (aka SecureBoot).
The Trusted Platform Module offers facilities for the secure generation of cryptographic keys, and limitation of their use, in addition to a random number generator. It also includes capabilities such as remote attestation and sealed storage.
- "Remote attestation" creates a nearly unforgeable hash-key summary of the hardware and software configuration. The program encrypting the data determines the extent of the summary of the software. This allows a third party to verify that the software has not been changed.
- "Binding" encrypts data using the TPM endorsement key, a unique RSA key burned into the chip during its production, or another trusted key descended from it.
- "Sealing" encrypts data in similar manner to binding, but in addition specifies a state in which the TPM must be in order for the data to be decrypted (unsealed).
Software can use a Trusted Platform Module to authenticate hardware devices. Since each TPM chip has a unique and secret RSAkey burned in as it is produced, it is capable of performing platform authentication.
Generally, pushing the security down to the hardware level in conjunction with software provides more protection than a software-only solution. However even where a TPM is used, a key would still be vulnerable while a software application that has obtained it from the TPM is using it to perform encryption/decryption operations, as has been illustrated in the case of a cold boot attack. This problem is eliminated if key(s) used in the TPM are not accessible on a bus or to external programs and all encryption/decryption is done in the TPM.
The primary scope of a TPM (in combination with other TCG implementations) is to assure the integrity of a platform. In this context "integrity" means "behave as intended" and a "platform" is generically any computer platform – not limited to PCs or just Windows: Start the power-on boot process from a trusted condition and extend this trust until the OS has fully booted and applications are running.
Together with the BIOS, the TPM forms a Root of Trust: The TPM contains several Platform Configuration Registers (PCR) that allow a secure storage and reporting of security relevant metrics. These metrics can be used to detect changes to previous configurations and derive decisions how to proceed. A good example can be found in Microsoft's BitLocker Drive Encryption (see below).
Therefore the BIOS and the Operating System have the primary responsibility to utilize the TPM to assure platform integrity. Only then can applications and users running on that platform rely on its security characteristics such as secure I/O "what you see is what you get", uncompromised keyboard entries, memory and storage operations.
"New BIOS implant tool debutting at CANSECWEST, like the NSA's NLS_933W.DLL, reprograms firmware, scrapes memory for secret PGP keys, defeats Tails or any OS in 2 minutes"
Lisa • March 23, 2015 8:01 AM
Of course hacking BIOS can now be considered so outdated now that Intel has a new generation of processors with vPro and AMT (Active Management Technology) with a separate hidden instruction set for PC management and remote 3G radio support which works independent of any OS that is suspected to can backdoors capable of hijacking any PC. (It even works when no OS is even installed or running.)
The FSF (Free Software Foundation) has expressed serious concerns:
Who is to say that Intel has not received its share of NSL's, during the design of these chips?
Minimialism is the best approach to security, since the most complex or feature rich something is, the more possible attack surfaces it has. Having vPro and AMT might have some legitimate corporate IT benefit to help remotely manage corporate "enterprise-grade" computers, but is risky and potential quite harmful for individual consumers, even though it is included in many new "consumer-grade" computers.
I know what a TPM is. I was asking how exactly it will protect your "device and network", as you put it.
Also, all of your links show the one use of the TPM what I described as it main job, that is protection of the firmware integrity, which together with secure boot ought to protect against tampering of the OS. What makes you think this part of the TPM is not in place? The TPM's visibility to the OS is independent from its ability to only boot unmodified firmware. And you only noted that you cannot see it from your OS.
Furthermore, I asked what OS you use. This is because e.g. with Windows everybody and their dogs can get their code signed to execute driver code (in kernel mode). Your shiny secure boot doesn't help at all. This has been shown (time and again) with malware and so-called APTs and seen in the wild. An active TPM will help you nothing if Windows executes the driver code in ring 0. But even if that was not the case (e.g. you run Linux and have created your own key to sign the kernel and all modules, have deactivated every other key in UEFI, have your private key only on an air-gapped system used only to sign the kernel, boot loader and modules) there would still be ways to execute code in kernel mode by exploiting bugs in the kernel. This is probably possible on Linux (kernel exploits are found every now and then) but even more so on Windows where tons of software (firewall, anti-virus/malware) come with device drivers, often exploitable in trivial ways, and parts of the GUI even run in ring 0. It is practically guaranteed that you can get local privilege escalation on Windows. The only thing which is made harder in such a setup is the persistence. Since ideally you cannot run code from disk which isn't signed (not really a problem on Windows, see above) persistence (across reboots) is made harder.
In other words: I would worry much more about other things, such as deactivating flash, running a hopefully secure browser, maybe in a sandbox etc. TPM doesn't really protect you once the code is on your machine.
SeeSKYLAKE NUC - PTT Platform Trust Technology - AES Encryption Coprocessor - TPM 2.0 Capabilities - System Hardening - When will Intel Visual BIOS be configured to allow for NUC system security and hardening?
Root-Kit and Boot-Kit viruses are the most nefarious exploits that compromise PCs because they go mostly undetected by virus scanning software and are persistent in the PC BIOS firmware despite reinstalling the OS.
"Slides from a CanSecWest presentation. The bottom line is that there are some pretty huge BIOS insecurities out there. We as a community and industry need to figure out how to regularly patch BIOSes."
What is Intel doing to restore confidence in the security of personal computing?
"It's time to demand better BIOS security from your OEM."