Generate Valid EC2 Dynamic Crypto Data

[naftulikay]

1 has dealt with almost every edge-case that I can find, outside of the instance identity stuff, which is largely cryptographic data signing a given document. There are a few keys in /${api_version}/dynamic/instance-identity/*:

• document: a JSON dictionary describing facts about the instance.
• rsa2048: an undocumented item which appears to be an RSA signature of document, which does embed the document data within itself.
• pkcs7: A PKCS#7 signature which embeds document within itself.
• signature: An unknown format of a signature over document without document embedded within it.

The most ideal thing to do would be to generate a valid set of signatures for our emended document such that, provided that clients use our cert, clients could successfully validate our data identically to the way that it normally works on EC2.

Unfortunately, this doesn't seem to be possible so I'm filing my findings here.

Next we will inspect the files and try to understand what's going on therein.

document

The actual document looks like this:

{
  "accountId" : "012345678901",
  "availabilityZone" : "us-west-2a",
  "ramdiskId" : null,
  "kernelId" : null,
  "pendingTime" : "2019-07-16T22:04:00Z",
  "architecture" : "x86_64",
  "privateIp" : "10.0.0.1",
  "devpayProductCodes" : null,
  "marketplaceProductCodes" : null,
  "version" : "2017-09-30",
  "region" : "us-west-2",
  "imageId" : "ami-deadbeefcafebabe",
  "billingProducts" : null,
  "instanceId" : "i-deadbeefcafebabe",
  "instanceType" : "t2.micro"
}

Pretty standard instance metadata, including region which isn't exposed elsewhere.

rsa2048

I am zero-indexing bytes.

Header

Bytes 0-53 (inclusive) appear to be a binary header of some format.

Python byte encoded:

b'0\x80\x06\t*\x86H\x86\xf7\r\x01\x07\x02\xa0\x800\x80\x02\x01\x011\x0b0\t\x06\x05+\x0e\x03\x02\x1a\x05\x000\x80\x06\t*\x86H\x86\xf7\r\x01\x07\x01\xa0\x80$\x80\x04\x82\x01\xde'

Hex encoding:

30 80 06 09 2A 86 48 86 F7 0D 01 07 02 A0 80 30 80 02 01 01 31 0B 30 09 06 05 2B 0E 03 02
1A 05 00 30 80 06 09 2A 86 48 86 F7 0D 01 07 01 A0 80 24 80 04 82 01 DE

This does not appear to be any ASCII data.

Document

After the header is the document in ASCII, in my case bytes 54 through 531 inclusive.

Footer

After the document, the footer begins at byte 532 and continues to the end of the document at byte 827.

Python byte encoded:

b'\x00\x00\x00\x00\x00\x001\x82\x01\x180\x82\x01\x14\x02\x01\x010i0\\1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x190\x17\x06\x03U\x04\x08\x13\x10Washington State1\x100\x0e\x06\x03U\x04\x07\x13\x07Seattle1 0\x1e\x06\x03U\x04\n\x13\x17Amazon Web Services LLC\x02\t\x00\x96\xbaH\xd9\xe5^\x1ag0\t\x06\x05+\x0e\x03\x02\x1a\x05\x00\xa0]0\x18\x06\t*\x86H\x86\xf7\r\x01\t\x031\x0b\x06\t*\x86H\x86\xf7\r\x01\x07\x010\x1c\x06\t*\x86H\x86\xf7\r\x01\t\x051\x0f\x17\r190716203739Z0#\x06\t*\x86H\x86\xf7\r\x01\t\x041\x16\x04\x14\xb3\xe4q\x1c><\xe3\x97\xe2\x9f*\xf3\x1c\xe9\xd94\x94\xc5%\x170\t\x06\x07*\x86H\xce8\x04\x03\x04/0-\x02\x148\xe8T\x8c\xc8\xa2@\xb2\xf2\x8e \x9f\xbf\xb8\xc9 ~\xd9\xba[\x02\x15\x00\x98}\x9bh\x99\xd8\xff_\xdc\xef\xf0;{S!4\x8ejI\x96\x00\x00\x00\x00\x00\x00'

Hex encoding:

00 00 00 00 00 00 31 82 01 18 30 82 01 14 02 01 01 30 69 30 5C 31 0B 30 09 06 03 55 04 06
13 02 55 53 31 19 30 17 06 03 55 04 08 13 10 57 61 73 68 69 6E 67 74 6F 6E 20 53 74 61 74
65 31 10 30 0E 06 03 55 04 07 13 07 53 65 61 74 74 6C 65 31 20 30 1E 06 03 55 04 0A 13 17
41 6D 61 7A 6F 6E 20 57 65 62 20 53 65 72 76 69 63 65 73 20 4C 4C 43 02 09 00 96 BA 48 D9
E5 5E 1A 67 30 09 06 05 2B 0E 03 02 1A 05 00 A0 5D 30 18 06 09 2A 86 48 86 F7 0D 01 09 03
31 0B 06 09 2A 86 48 86 F7 0D 01 07 01 30 1C 06 09 2A 86 48 86 F7 0D 01 09 05 31 0F 17 0D
31 39 30 37 31 36 32 30 33 37 33 39 5A 30 23 06 09 2A 86 48 86 F7 0D 01 09 04 31 16 04 14 
B3 E4 71 1C 3E 3C E3 97 E2 9F 2A F3 1C E9 D9 34 94 C5 25 17 30 09 06 07 2A 86 48 CE 38 04
03 04 2F 30 2D 02 14 38 E8 54 8C C8 A2 40 B2 F2 8E 20 9F BF B8 C9 20 7E D9 BA 5B 02 15 00
98 7D 9B 68 99 D8 FF 5F DC EF F0 3B 7B 53 21 34 8E 6A 49 96 00 00 00 00 00 00

Hexedit's attempt to deserialize:

anceType" : "t2.micro".}......1.
..0......0i0\1.0...U....US1.0...
U....Washington State1.0...U....
Seattle1 0...U....Amazon Web Ser
vices LLC....K.Z..$.0...`.H.e...
....i0...*.H......1...*.H......0
...*.H......1...190716203739Z0/.
.*.H......1". m*...%......>.~.l.
...KbS.cQ.....0...*.H...........
.ib..-...`....y.z. Y..I.~=.8....
=JMR.......z...k.C.I.#.gm..G.G..
...$.w..>F.[...T].|%....2.fa.P..
c....:-..aZ..{..I6..n4.!.....z.@
...~....{ .K.".w.yz......IG...-.
md.c$.....3..?BP..&..,...Wu%.YOK
y..._....!...~..,C..r..4.-dxy`.F
`.T..Z....D.}ih....f...;....J.)o
.......

Notable are the strings "Amazon Web Services LLC", "Seattle", "Washington State", etc. This is probably DER encoded data, though I don't know that only a handful of bytes (296 bytes). I assume this is the signature portion with parts of the public key embedded.

pkcs7

Similar to rsa2048 above, this is composed of a header, body, and footer. The header is 54 bytes of binary data, the body is document, and the footer is 296 bytes long and includes some similar certificate-esque metadata.

signature

This file is 128 bytes long and appears to be a constant-size signature with no non-binary data.

[naftulikay]

This is all the time I'm willing to invest in this for now. The purpose of this appears to allow instances to verify cryptographically that they are indeed in AWS using AWS' public cert, the given document, and the PKCS-7 signature.