10

UPDATE: Proof of concept code here, console output shown below and all involved certificates are here.

Just noticed that ECDiffieHellmanCng.DeriveKeyMaterial(...) behaves differently on Windows 8.1 Enterprise (x64) and Windows 10 Prof (x64).

Specifically, when doing something like

byte[] SymKey12 = party1.DeriveKeyMaterial(party2);
byte[] SymKey21 = party2.DeriveKeyMaterial(party1);

the values of SymKey12 and SymKey21 are different on Windows 10 for several ECDH secp384 and ECDH secp521 scenarios that passed just fine on Windows 8.1.

Any ideas?

Windows Server 2016 Tech Preview 3 (version NT 10.0.10514.0) and Windows 10 output (version NT 10.0.10240.0)

'Test ECC Alice secp521r1 SS' <=> 'Test ECC Bob secp521r1 SS'
> FAILURE < ECDH Keys are different!
SymKey12 = 22-46-6B-15-0F-9B-65-B0-D6-7D-AA-0E-C5-8A-7F-F3-18-1F-5F-62-88-26-90-67-DC-99-1B-98-73-3B-58-FF
SymKey21 = FD-C3-24-27-4C-4C-56-01-62-1E-B2-AE-B1-F6-68-64-61-72-EB-2E-6D-F4-30-21-F1-8A-73-C6-85-38-25-FA
------------------------------
'Test ECC Alice secp384r1 SS' <=> 'Test ECC Bob secp384r1 SS'
> FAILURE < ECDH Keys are different!
SymKey12 = F3-55-B0-72-49-DA-A5-6B-D7-3E-B7-F5-87-E7-4B-D1-20-A1-6E-67-EE-FF-C2-A9-12-E4-B0-20-46-F7-A5-FA
SymKey21 = 8C-63-5E-21-AC-BB-C1-AB-17-73-E2-E9-4D-95-20-07-6A-60-69-B1-E6-3B-18-EA-B6-56-FF-38-9F-F8-46-2F
------------------------------
'Test ECC Alice secp256r1 SS' <=> 'Test ECC Bob secp256r1 SS'
Success, ECDH Keys agree
------------------------------
'Alice secp521 test cert' <=> 'Bob secp521 test cert'
> FAILURE < ECDH Keys are different!
SymKey12 = B3-90-1C-1B-B0-66-BB-D8-A2-46-37-A9-E4-84-1F-FE-B8-ED-14-17-A8-D8-0C-EB-20-A0-98-5F-3A-85-73-3D
SymKey21 = 44-62-AD-3F-DA-D4-7E-17-49-05-C4-22-93-DD-36-B7-0D-28-47-93-E5-D4-63-03-00-BC-F8-99-DF-BA-A3-92
------------------------------
'Alice secp384 test cert' <=> 'Bob secp384 test cert'
Success, ECDH Keys agree
------------------------------
'Alice secp256 test cert' <=> 'Bob secp256 test cert'
Success, ECDH Keys agree
------------------------------
Press any key to exit ...

Windows 8 output (version NT 6.3.9600.0)

'Test ECC Alice secp521r1 SS' <=> 'Test ECC Bob secp521r1 SS'
Success, ECDH Keys agree
------------------------------
'Test ECC Alice secp384r1 SS' <=> 'Test ECC Bob secp384r1 SS'
Success, ECDH Keys agree
------------------------------
'Test ECC Alice secp256r1 SS' <=> 'Test ECC Bob secp256r1 SS'
Success, ECDH Keys agree
------------------------------
'Alice secp521 test cert' <=> 'Bob secp521 test cert'
Success, ECDH Keys agree
------------------------------
'Alice secp384 test cert' <=> 'Bob secp384 test cert'
Success, ECDH Keys agree
------------------------------
'Alice secp256 test cert' <=> 'Bob secp256 test cert'
Success, ECDH Keys agree
------------------------------
Press any key to exit ...
DeepSpace101
  • 2,143
  • 3
  • 22
  • 35
  • As a workaround, see if BouncyCastle can issue the correct output. If I don't see answer in a few days, I'll open a Premier / EA case w MSFT. – makerofthings7 Aug 02 '15 at 18:57
  • @LamonteCristo: Sorry, can you clarify that? Do you mean the workaround via [RFC4050 XML representation](https://github.com/sidshetye/win10secp384Issue/blob/master/Win10secp384/Program.cs#L103) of an EC public key that's used for the [ECDiffieHellmanCngPublicKey](https://github.com/sidshetye/win10secp384Issue/blob/master/Win10secp384/Program.cs#L87)? Seems like that RFC4050 XML format is fine ... – DeepSpace101 Aug 02 '15 at 23:10
  • It's a bit of a strange thing if key agreement suddenly fails, but it still may be an encoding or human error (mixing keys from key pairs). We cannot tell without the input (public keys and - if possible - private keys) right before the key agreement takes place. – Maarten Bodewes Sep 19 '15 at 22:09

3 Answers3

3

Update: Fixed in KB3093266 (https://support.microsoft.com/en-us/kb/3093266)

Run the following in a PowerShell window to see if you have it ...

Get-HotFix -id KB3093266

Sources confirm that this is indeed a bug. The issue related to parsing PFX files in Windows 10 and Windows Server 2016 Beta when the certificates and private keys are initially installed.

The fix should be out in a security update sometime in Sept 2015. Honestly, we're pretty surprised to be the only ones really using elliptic curve crypto on Windows since ours seems to be the original report.

DeepSpace101
  • 2,143
  • 3
  • 22
  • 35
  • AFAIK this does not fix the problems I've described below, I may have to bug them again... – larsw Oct 08 '15 at 08:34
0

I just want to add some details; I've also stumbled into these blocking changes in the CNG subsystem.

In the following gist, there are two files; one that describes some scenarios that works on Win7/Win8.1 but not on Win10, and one that describes some workarounds on Win10 - but not how to acquire a crypto context and get the underlying CNG private key of a X.509 certificate :-/

https://gist.github.com/larsw/2c45147a242ceb079f5d

Last unofficial updates from Microsoft is that this will be addressed next Patch Tuesday (if I've counted correctly, October 13th).

larsw
  • 101
  • 1
0

Don't have the reputation to add a comment..

..but can you list what versions of .NET you are targeting against? Do you get the same result on Windows 8.1 when targeting (and forcing in app config file) .NET Framework 4.6?

Different versions of Windows came with different versions of .NET : https://en.wikipedia.org/wiki/.NET_Framework#Versions

I also learnt recently that a machine with .NET 4 only will still attempt to run an application targeting .NET 4.5+

If the version of the .NET Framework that the app was built on is not present and a configuration file does not specify a version in a element, the app tries to run on the latest version of the .NET Framework that is present on the user's computer.

https://msdn.microsoft.com/en-us/library/jj152935%28v=vs.110%29.aspx

Matthew1471
  • 1,124
  • 10
  • 14