I have a RSA 1024 key pair generated using standard call from PKCS#11.
I need to generate a PKCS#10 CSR for the public key.
MS has the IEnroll4 dll which will allow to raise a CSR using createRequestWStr. The samples indicate that you need to generate a new key pair(a container with 2 objects in MS CAPI) and MS automatically gives the the public key context for csr generation.
In my case, I already have a key pair generated using pkcs#11(as 2 objects but no key container). MS dll is not allowing me to proceed further.
QUERY 1:
Can some body point out how I can resolve this issue.
----------------------------------------------------------------------------
Alternatively, I was thinking to write my own code for CSR generation based on RSA standards. I am having the ASN 1.0 format
The ASN.1 syntax for a Certification Request is:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature
}
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Signature ::= BIT STRING
CertificationRequestInfo ::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes
}
Attributes ::= SET OF Attribute
QUERY 2:
How do I use the above syntaxes? I am totally new to this syntax? Which resources should I need to look at to write my own code?
If you need to generate your certificate-request with the PKCS#11-interface (i.e. you cannot use a CSP-interface instead) your best bet is to avoid IEnroll.
For C++ your (free and open source) options seems to be to look into OpenSSL or Botan. I am not terribly fond of OpenSSL's API, but it works. I have never used Botan, but it seems pretty nice. There are also many excellent choices if you are willing to pay for them.
Alternatively, if you want to write the ASN.1 yourself you probably want to read A Layman's Guide to a Subset of ASN.1, BER, and DER. The formal specifications are in X.208 and X.209, but those are hard reading.
You want to generate a DER encoding of the ASN.1 (that is described in the link).
Here is an example encoding:
308201493081b3020100300e310c300a06035504031303666f6f30819d300d06092a864886f70d01
0101050003818b00308187028181009c921beeef551bcb051518f0c48bfe72cb1d5609a64a005e0c
008580bb81b3a43cea280d5bffa4e777733845fc2f485f1c8ccc0b2914f30d1e41369fd4a6758a3c
c887834c4d6177bd96b9f341232b00d453f28f2ae5ad5e3b0324d0b5b440a0901968fd556470dd4d
2ea2e99dd99c580703c042853265374cd3622f6c3369e5020103300d06092a864886f70d01010505
000381810068c0266a16117b37fb15ad143e2941ff8b8f082daf4ec02789db01636f51c739f199fb
19c56228cc12b9e482b966f8650fa3fdb24e31e97eef15f61aabc91dc194aeba4ebce5eab0c5e3db
36cc090a0e4b2c7d3ac27eeb0d3900d73bd88172464b890a8f9a58a0d34c0f5e226b6173cc92a316
4bbbf1d12f29d1e2ad3f36c977
or translated with the excellent dumpasn1 utility:
0 30 329: SEQUENCE {
4 30 179: SEQUENCE {
7 02 1: INTEGER 0
10 30 14: SEQUENCE {
12 31 12: SET {
14 30 10: SEQUENCE {
16 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
21 13 3: PrintableString 'foo'
: }
: }
: }
26 30 157: SEQUENCE {
29 30 13: SEQUENCE {
31 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
42 05 0: NULL
: }
44 03 139: BIT STRING 0 unused bits, encapsulates {
48 30 135: SEQUENCE {
51 02 129: INTEGER
: 00 9C 92 1B EE EF 55 1B CB 05 15 18 F0 C4 8B FE
: 72 CB 1D 56 09 A6 4A 00 5E 0C 00 85 80 BB 81 B3
: A4 3C EA 28 0D 5B FF A4 E7 77 73 38 45 FC 2F 48
: 5F 1C 8C CC 0B 29 14 F3 0D 1E 41 36 9F D4 A6 75
: 8A 3C C8 87 83 4C 4D 61 77 BD 96 B9 F3 41 23 2B
: 00 D4 53 F2 8F 2A E5 AD 5E 3B 03 24 D0 B5 B4 40
: A0 90 19 68 FD 55 64 70 DD 4D 2E A2 E9 9D D9 9C
: 58 07 03 C0 42 85 32 65 37 4C D3 62 2F 6C 33 69
: [ Another 1 bytes skipped ]
183 02 1: INTEGER 3
: }
: }
: }
: }
186 30 13: SEQUENCE {
188 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
199 05 0: NULL
: }
201 03 129: BIT STRING 0 unused bits
: 68 C0 26 6A 16 11 7B 37 FB 15 AD 14 3E 29 41 FF
: 8B 8F 08 2D AF 4E C0 27 89 DB 01 63 6F 51 C7 39
: F1 99 FB 19 C5 62 28 CC 12 B9 E4 82 B9 66 F8 65
: 0F A3 FD B2 4E 31 E9 7E EF 15 F6 1A AB C9 1D C1
: 94 AE BA 4E BC E5 EA B0 C5 E3 DB 36 CC 09 0A 0E
: 4B 2C 7D 3A C2 7E EB 0D 39 00 D7 3B D8 81 72 46
: 4B 89 0A 8F 9A 58 A0 D3 4C 0F 5E 22 6B 61 73 CC
: 92 A3 16 4B BB F1 D1 2F 29 D1 E2 AD 3F 36 C9 77
: }
Related
I'm trying to understang which TLS version is used based on this logs (http trace)
System.Net Information: 0 : [2544] SecureChannel#49129953::.AcquireClientCredentials, new SecureCredential() (flags=(ValidateManual, NoDefaultCred, SendAuxRecord), m_ProtocolFlags=(Ssl3Client, Tls10Client), m_EncryptionPolicy=RequireEncryption)
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0a 02 82 01 01 00 b8 de 6a 2c a0 05 1d c1 2e 54 2d de 74 40 a6 83 2b 81 25 29 8d c1 2b e1 4d 4b 63 bd 7f c0 75 fe 15 eb 6b a6 2f 3c 65 d6 7a 55 dc 68 07 1c 6c 2e 8c cd d5 01 74 9f ca ca bb 5e b0 6d 9a 44 d1 1c 74 11 ca 4f 44 fa 59 59 22 f5 f9 c2 00 21 d6 1d a3 09 5a 0e fe da b7 ea d2 c8 55 51 c7 53 90 d1 b9 bf 2c 98 49 75 82 30 ....
System.Net Information: 0 : [2544] SecureChannel#49129953 - Remote certificate was verified as valid by the user.
System.Net Information: 0 : [2544] ProcessAuthentication(Protocol=Tls, Cipher=Aes128 128 bit strength, Hash=Sha1 160 bit strength, Key Exchange=RsaKeyX 2048 bit strength).
Any idea? If you need more log let me know.
Thank you
... m_ProtocolFlags=(Ssl3Client, Tls10Client)
... ProcessAuthentication(Protocol=Tls
Based on this it should be TLS 1.0. For other versions like TLS 1.2 there is probably something like Protocol=Tls12 instead
I am trying to add an NODE_MCU_V3 to a small BMS system I have running with Raspberry's and a Java library.
The device makes a call to the server, and gets a JSON response. This response is DES encrypted and then Base64 encoded. The sending of the information works fine with encoding, and receiving a response works on smaller responses. But if the JSON is more than 208 characters the decryption fails. I am not that familiar with Arduino and C but would have a guess it has to do with the size.
This is the relevant code. The result is a String taken from the server response.
The result of the Base64 decoder is what is expected, the problem is with the DES decipher. I added examples to the bottom in HEX.
char encoded[result.length()];
result.toCharArray(encoded, result.length());
// Convert back.
int decodedLength = Base64.decodedLength(encoded, sizeof(encoded));
char decodedChar[decodedLength];
Base64.decode(decodedChar, encoded, sizeof(encoded));
Serial.print("Decoded: "); printArray((byte*) decodedChar, sizeof(decodedChar));
byte jsonByte[decodedLength];
for (int i = 0; i < (des.get_size() / 8); i++) {
byte intermitInput[8];
byte intermitResult[8];
for (int j = 0; j < 8; j++) {
intermitInput[j] = (byte) decodedChar[(i * 8) + j];
}
des.decrypt(intermitResult, intermitInput, key);
for (int j = 0; j < 8; j++) {
jsonByte[(i * 8) + j] = intermitResult[j];
}
}
Serial.print("Decrypted: "); printArray(jsonByte, sizeof(jsonByte));
char json[sizeof(jsonByte) + 1];
for (int i = 0; i < sizeof(jsonByte); i++) {
json[i] = (char)jsonByte[i];
}
json[sizeof(jsonByte)] = '\0';
Serial.print("Decripted result:\t");
Serial.println(json);
StaticJsonDocument<256> doc;
DeserializationError error = deserializeJson(doc, json);
// Test if parsing succeeds.
if (error) {
Serial.print(F("deserializeJson() failed."));
return;
}
const char* resultStatus = doc["result"];
if (strstr(resultStatus, "SUCCESS") < 0) {
Serial.print("Problem with the response: "); Serial.println(resultStatus);
return;
}
Serial.print(" Value: "); Serial.println(resultStatus);
Server:
Json - Datalength: 359 - {"result":"SUCCESS","message":"(none)", "actions":[{"action":"initiation","data":[{"type":"IO_CONTROLLER","inputPins":"","outputPinsManual":"","relayDefaultState":"","inputResistance":"","inputPinsManual":"","outputPins":"4"}], "hostname":"AR-259bfc91250", "macAddress":"null"},{"action":"campAlarm","value":"false"},{"action":"warningBeep","value":"false"}]}
Clear JSON HEX: 7b22726573756c74223a2253554343455353222c226d657373616765223a22286e6f6e6529222c2022616374696f6e73223a5b7b22616374696f6e223a22696e6974696174696f6e222c2264617461223a5b7b2274797065223a22494f5f434f4e54524f4c4c4552222c22696e70757450696e73223a22222c226f757470757450696e734d616e75616c223a22222c2272656c617944656661756c745374617465223a22222c22696e707574526573697374616e6365223a22222c22696e70757450696e734d616e75616c223a22222c226f757470757450696e73223a2234227d5d2c2022686f73746e616d65223a2241522d3235396266633931323530222c20226d616341646472657373223a226e756c6c227d2c7b22616374696f6e223a2263616d70416c61726d222c2276616c7565223a2266616c7365227d2c7b22616374696f6e223a227761726e696e6742656570222c2276616c7565223a2266616c7365227d5d7d
Encrypted before Base64: 1e64fd8c074b2eda044f2ed820dab06949e5a2c5602918b13779e906c2733c1719965a456e2127fef0c910cbbbfcd137c535c9423cc14e7e8497de8fd340441f0a48634ccaa6d64e5d23bd2bc4f06d3998adc310f77631d17478f8c85168663e9ecba5551d1bac0c06b26e778a96e4292de903683e4fadeb5c94050f7b30aa1de5a11408a366bef1584115b530ea4b9efffcc0abef06ed6b0baca92b67ef54587eaa0e71976261eacf7942ec2a566d962246ebf7aeacda6d4a6b5246ca2281cf1e6db1af905a5260c74276ba7bcbba00e4ce82abb260f606afee1277f7cbf42ab3cac3cc09c5fb9676c5feb30c47dcd437d64a7886376435eeee517e14673b45ead6ddf30b238e46c53f6bbbedbab1e74ca1fbb5dbac628a12ae007471017d969757d37a2ffa5f992c5ecc9c9fad3f500638b7a135695eba21b54947a3492fdc98b3a2570fbea4bae0d50d426152ee8012779de0f5ba9e96ae15cef583353a3116499bea9e766488
Base64 send: HmT9jAdLLtoETy7YINqwaUnlosVgKRixN3npBsJzPBcZllpFbiEn/vDJEMu7/NE3xTXJQjzBTn6El96P00BEHwpIY0zKptZOXSO9K8TwbTmYrcMQ93Yx0XR4+MhRaGY+nsulVR0brAwGsm53ipbkKS3pA2g+T63rXJQFD3swqh3loRQIo2a+8VhBFbUw6kue//zAq+8G7WsLrKkrZ+9UWH6qDnGXYmHqz3lC7CpWbZYiRuv3rqzabUprUkbKIoHPHm2xr5BaUmDHQna6e8u6AOTOgquyYPYGr+4Sd/fL9CqzysPMCcX7lnbF/rMMR9zUN9ZKeIY3ZDXu7lF+FGc7RerW3fMLI45GxT9ru+26sedMofu126xiihKuAHRxAX2Wl1fTei/6X5ksXsycn60/UAY4t6E1aV66IbVJR6NJL9yYs6JXD76kuuDVDUJhUu6AEned4PW6npauFc71gzU6MRZJm+qedmSI
Arduino:
Base64 coming in: HmT9jAdLLtoETy7YINqwaUnlosVgKRixN3npBsJzPBcZllpFbiEn/vDJEMu7/NE3xTXJQjzBTn6El96P00BEHwpIY0zKptZOXSO9K8TwbTmYrcMQ93Yx0XR4+MhRaGY+nsulVR0brAwGsm53ipbkKS3pA2g+T63rXJQFD3swqh3loRQIo2a+8VhBFbUw6kue//zAq+8G7WsLrKkrZ+9UWH6qDnGXYmHqz3lC7CpWbZYiRuv3rqzabUprUkbKIoHPHm2xr5BaUmDHQna6e8u6AOTOgquyYPYGr+4Sd/fL9CqzysPMCcX7lnbF/rMMR9zUN9ZKeIY3ZDXu7lF+FGc7RerW3fMLI45GxT9ru+26sedMofu126xiihKuAHRxAX2Wl1fTei/6X5ksXsycn60/UAY4t6E1aV66IbVJR6NJL9yYs6JXD76kuuDVDUJhUu6AEned4PW6npauFc71gzU6MRZJm+qedmSI
Base64 Decoded: 1E 64 FD 8C 07 4B 2E DA 04 4F 2E D8 20 DA B0 69 49 E5 A2 C5 60 29 18 B1 37 79 E9 06 C2 73 3C 17 19 96 5A 45 6E 21 27 FE F0 C9 10 CB BB FC D1 37 C5 35 C9 42 3C C1 4E 7E 84 97 DE 8F D3 40 44 1F 0A 48 63 4C CA A6 D6 4E 5D 23 BD 2B C4 F0 6D 39 98 AD C3 10 F7 76 31 D1 74 78 F8 C8 51 68 66 3E 9E CB A5 55 1D 1B AC 0C 06 B2 6E 77 8A 96 E4 29 2D E9 03 68 3E 4F AD EB 5C 94 05 0F 7B 30 AA 1D E5 A1 14 08 A3 66 BE F1 58 41 15 B5 30 EA 4B 9E FF FC C0 AB EF 06 ED 6B 0B AC A9 2B 67 EF 54 58 7E AA 0E 71 97 62 61 EA CF 79 42 EC 2A 56 6D 96 22 46 EB F7 AE AC DA 6D 4A 6B 52 46 CA 22 81 CF 1E 6D B1 AF 90 5A 52 60 C7 42 76 BA 7B CB BA 00 E4 CE 82 AB B2 60 F6 06 AF EE 12 77 F7 CB F4 2A B3 CA C3 CC 09 C5 FB 96 76 C5 FE B3 0C 47 DC D4 37 D6 4A 78 86 37 64 35 EE EE 51 7E 14 67 3B 45 EA D6 DD F3 0B 23 8E 46 C5 3F 6B BB ED BA B1 E7 4C A1 FB B5 DB AC 62 8A 12 AE 00 74 71 01 7D 96 97 57 D3 7A 2F FA 5F 99 2C 5E CC 9C 9F AD 3F 50 06 38 B7 A1 35 69 5E BA 21 B5 49 47 A3 49 2F DC 98 B3 A2 57 0F BE A4 BA E0 D5 0D 42 61 52 EE 80 12 77 9D E0 F5 BA 9E 96 AE 15 CE F5 83 35 3A 31 16 49 9B EA 9E 76 64 7F
Decrypted HEX: 7B 22 72 65 73 75 6C 74 22 3A 22 53 55 43 43 45 53 53 22 2C 22 6D 65 73 73 61 67 65 22 3A 22 28 6E 6F 6E 65 29 22 2C 20 22 61 63 74 69 6F 6E 73 22 3A 5B 7B 22 61 63 74 69 6F 6E 22 3A 22 69 6E 69 74 69 61 74 69 6F 6E 22 2C 22 64 61 74 61 22 3A 5B 7B 22 74 79 70 65 22 3A 22 49 4F 5F 43 4F 4E 54 52 4F 4C 4C 45 52 22 2C 22 69 6E 70 75 74 50 69 6E 73 22 3A 22 22 2C 22 6F 75 74 70 75 74 50 69 6E 73 4D 61 6E 75 61 6C 22 3A 22 22 2C 22 72 65 6C 61 79 44 65 66 61 75 6C 74 53 74 61 74 65 22 3A 22 22 2C 22 69 6E 70 75 74 52 65 73 69 73 74 61 6E 63 65 22 3A 22 22 2C 22 69 6E 70 75 74 50 69 6E 73 4D 61 6E 75 61 6C 22 3A 22 22 2C 42 89 FE 3F 00 00 00 00 0D 0A 00 25 35 78 20 40 42 89 FE 3F D0 00 00 00 20 00 00 00 C7 08 10 40 09 00 00 00 00 00 00 00 F0 A7 C6 4B 0F 00 00 00 54 58 20 40 10 E9 FE 3F 40 89 FE 3F 60 58 20 40 54 58 20 40 10 E9 FE 3F 40 89 FE 3F 21 5B 20 40 C8 FB FF 3F 60 FA FF 3F 10 E9 FE 3F 18 5C 20 40 54 58 20 40 10 E9 FE 3F ED 88 FE 3F 5E 15 20 40 68 01 00 00 10 E9 FE 3F ED 88 FE 3F 21 5B 20 40 10 E9 FE 3F 68 01 00 00 00 00 00 00 B0 FD FF 3F 10 E9 FE 3F 68 01 00 00
Decrypted JSON String: {"result":"SUCCESS","message":"(none)", "actions":[{"action":"initiation","data":[{"type":"IO_CONTROLLER","inputPins":"","outputPinsManual":"","relayDefaultState":"","inputResistance":"","inputPinsManual":"",B⸮⸮?
If you suspect you are running out of memory, You can try to reclaim memory buffers by dual-purposing them. For example, reuse the input buffer that contained the base64 data fto store the decoded json, this will save you at least 208 byes of RAM. It may be enough for your case. All you'd need to do to test this theory is this:
byte* jsonByte = (byte*)encoded; // save decodedLength bytes of RAM
For futher savings, you can also try to decode the base64 in-place, using a single buffer for both input and output. If your base64 decode can't do it (it likely can), then write your own that can, it's definitely feasible for very little pain. This can save you another 208 bytes, which is quite a lot. For testing this, change the declarion of decodedChar to:
char* decodedChar = encoded;
Base64.decodedLength() will always return (result.length() * 5) / 8, which is always smaller than the number of bytes coming in.
Also, there are more potential savings in the decryption. For one, the decryption can be done in_place.
for (int i = 0; i < (des.get_size() / 8); i++) {
byte intermitInput[8];
byte intermitResult[8]; // not needed
for (int j = 0; j < 8; j++) {
intermitInput[j] = (byte) decodedChar[(i * 8) + j];
}
des.decrypt(intermitResult, intermitInput, key);
for (int j = 0; j < 8; j++) {
jsonByte[(i * 8) + j] = intermitResult[j];
}
}
// could be done in-place with no loss of functionality,
// and a noticeable performance gain. Copying data takes
// time, too.
for (int i = 0; i < des.get_size(); i += 8) {
byte intermitInput[8];
for (int j = 0; j < 8; j++) {
intermitInput[j] = (byte) decodedChar[i + j];
}
des.decrypt((byte*)decodedChar + i, intermitInput, key);
}
// result is in array decodedCher. array jsonBytes is not needed anymore.
And here:
// you use 208 bytes of RAM only to add a null terminating character.
// when you coud have simply allocated 1 more byte in jsonByte[], avoided
// this entire loop, and made your function run faster at the same time.
char json[sizeof(jsonByte) + 1];
for (int i = 0; i < sizeof(jsonByte); i++) {
json[i] = (char)jsonByte[i];
}
json[sizeof(jsonByte)] = '\0';
My estimate is that you can reclaim at least 600 bytes of RAM in this function, which would alow you to process larger jsons.
With the details given in your question, it is impossible to give you an estimate of how large a json you'd be able to process.
Also, since your arduino bugs in printArray(), I'd check in there for any less than useful large intermediate arrays. In a print function, any array larger than 16 bytes would already be way too big for the task at hand. Ideally there should be no intermediate array at all in a print function.
To recap: You can and should reorganize your code to use only one array for input, all intermediate results and the final json. RAM resources are very limited on small microprocessors and Arduinos. With use, you will notice that embedded algorithms and libraries, like the DES encryption, are especially built so resource cost is as small as possible.
Another area to explore: Is the json result parsed by the Arduino? If not, the entire sequence could very likely be done 8 bytes at a time, read in a block of 10 bytes, and send the resulting 8 bytes to the Pi as you go, giving you the priceless capability to process jsons of unlimited size, at least on the arduino side of things.
I've generated a public key using openssl
BIGNUM* e = BN_new();
BN_set_word(e, 17);
RSA* rsa = RSA_new();
if(!RSA_generate_key_ex(rsa, 2048, e, NULL)) {
LOG(security, debug) << "failed to generate private key";
}
And these are written to files:
FILE* pubwriter = fopen("key.pub", "wb");
int err = PEM_write_RSAPublicKey(pubwriter, key);
if(!err) {
throw new std::runtime_error("Failed to store public key");
}
FILE* privwriter = fopen("key.priv", "wb");
std::string password = "password";
err = PEM_write_RSAPrivateKey(privwriter, key, EVP_des_ede3_cbc(),
(unsigned char*)password.c_str(),
password.size(), NULL, NULL);
And they seem to be stored correctly, key.pub then contains something like
-----BEGIN RSA PUBLIC KEY-----
MIIBCAKCAQEA0rG1b0g3NIsDT8HkzgTx8BUI9LhueWbH1NuAvIh9qTF57GzEXuTu
jxBcuSzWXlR83ci4oITp7VqV6KLVoJryf8orGXBVi9A73JYOQVB6FEzARKym/g8E
fSEwSmdQ4NfiTESwOCtIextdu3x8pANSYDyyqdiWsSHy0SiZmkbvdVYomIBJZOV9
jhb3mkmD0WUYie9AXziTbli97YqDiN168kMI+7ePpbNJFSVSIUkPPocSgvgcAux/
HuDqftzBgyAF3NGb3AAra1A8T7yPOqLyYyXdIJmF+/Svk5PdMbZVE/U76cjBThch
Q9AiLo25hOjkmtuEQubCuwrUDleblr93aQIBEQ==
-----END RSA PUBLIC KEY-----
Now I want to try these to make sure I haven't got anything wrong but it wont' load:
$ openssl rsautl -encrypt -inkey key.pub -pubin -in data.txt -out enc.txt
unable to load Public Key
What am I missing?
int err = PEM_write_RSAPublicKey(pubwriter, key);
PEM_write_RSAPublicKey writes just the public key. You can make the command work using PEM_write_PUBKEY. The various *_PUBKEY routines write the SubjectPublicKeyInfo, which includes the algorithm OID and public key.
When you write the SubjectPublicKeyInfo, OpenSSL calls it "traditional" format. It will also have the header -----BEGIN PUBLIC KEY----- (and not -----BEGIN RSA PUBLIC KEY-----).
Below, I used PEM_write_PUBKEY to save the public key rsa-public.pem:
$ openssl rsautl -encrypt -inkey rsa-public.pem -pubin -in data.txt -out enc.bin
$ hexdump enc.bin
0000000 45 53 31 ad 9d 6a c4 37 1e 22 4b 83 c6 27 c8 3c
0000010 df cb 87 a4 60 d8 63 9a 83 9f ee ca e5 8f 8e dd
0000020 d4 d0 98 97 1c b3 36 55 f1 84 ea 7f fe bf 22 b6
0000030 93 20 a2 d5 b2 bd 20 cc 52 8e c7 1b 33 e6 40 40
0000040 cb 7d 6f 17 f1 eb f1 d4 9d 66 fb 67 eb 67 ba 2a
0000050 44 c2 52 15 54 8d 79 76 ad 26 61 35 27 9c bb 6c
0000060 5b 0e 79 b3 d3 27 0b a9 72 17 0d 2d 19 d7 60 19
0000070 16 46 80 4b c0 ae 75 53 9e 6f f5 24 d9 1a a3 6a
0000080 2f 38 13 f6 72 19 20 94 de 40 75 20 51 f4 08 f4
0000090 74 b8 ac 49 01 d6 f8 f4 e5 79 38 88 2d 02 b7 bd
00000a0 f7 63 c1 e1 e5 ec 39 a1 fa 7c ce 0f 83 16 70 7e
00000b0 cd 7e f5 6b 51 c2 db d7 f6 c4 46 5d e5 93 d3 3d
00000c0 ab e6 3b 1a 97 d4 c9 54 e7 aa 90 2d 0a b9 c2 4b
00000d0 3c 58 fd 26 58 5a 63 c0 8c ae b9 72 24 a1 68 5d
00000e0 83 d7 5b ae 56 2a 78 46 8c f4 21 96 bd d3 0c 93
00000f0 8e 35 61 9c b8 56 2e 3a 4e 05 d9 1e 0b 59 14 11
0000100
PEM_write_PUBKEY requires a EVP_PKEY. Just use something like:
EVP_PKEY* pkey = EVP_PKEY_new();
ASSERT(pkey != NULL);
int rc = EVP_PKEY_set1_RSA(pkey, rsa);
ASSERT(rc == 1);
...
EVP_PKEY_free(pkey);
The set1 bumps the reference count on the RSA key, so you have to free it through EVP_PKEY_free.
The difference between PEM_write_RSAPublicKey and PEM_write_PUBKEY is very obvious when you save in ASN.1/DER. But it gets lost in the PEM encoding.
Here's the non-traditional key in ASN.1/DER and dumped. Its the ASN.1 equivalent of PEM_write_RSAPublicKey. Its just {n,e}:
$ dumpasn1 rsa-public-1.der
0 266: SEQUENCE {
4 257: INTEGER
: 00 D1 C8 05 BF AC 04 72 AA 0E 84 FB 47 75 59 97
: E1 81 65 0B 0A 1D 9D 2A A8 A1 E0 B1 14 5D 57 69
: D4 D2 E2 C6 64 54 94 C2 92 CC C7 99 1A 97 89 72
: F6 36 6A A7 B8 34 2C AB A9 CB 77 EB 0D A1 4E 72
: 24 9F 96 D6 1C 28 ED 44 E8 0B 22 7F F3 5B 52 E2
: 7E A6 5E F1 7C A2 29 4F F1 8B 9D 0F 94 27 05 D5
: BD 2E 1A AD B4 12 0D E0 69 3E 0B 1B A7 F8 71 B5
: AD 22 4B 18 FF 72 88 F3 C5 77 B0 CF 88 5C F4 19
: [ Another 129 bytes skipped ]
265 3: INTEGER 65537
: }
0 warnings, 0 errors.
Here's the traditional public key in ASN.1/DER and dumped. Its the ASN.1 equivalent of PEM_write_PUBKEY. Its the one that writes the SubjectPublicKeyInfo, and it includes an algorithm OID and public key:
$ dumpasn1 rsa-public-2.der
0 290: SEQUENCE {
4 13: SEQUENCE {
6 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
17 0: NULL
: }
19 271: BIT STRING, encapsulates {
24 266: SEQUENCE {
28 257: INTEGER
: 00 D1 C8 05 BF AC 04 72 AA 0E 84 FB 47 75 59 97
: E1 81 65 0B 0A 1D 9D 2A A8 A1 E0 B1 14 5D 57 69
: D4 D2 E2 C6 64 54 94 C2 92 CC C7 99 1A 97 89 72
: F6 36 6A A7 B8 34 2C AB A9 CB 77 EB 0D A1 4E 72
: 24 9F 96 D6 1C 28 ED 44 E8 0B 22 7F F3 5B 52 E2
: 7E A6 5E F1 7C A2 29 4F F1 8B 9D 0F 94 27 05 D5
: BD 2E 1A AD B4 12 0D E0 69 3E 0B 1B A7 F8 71 B5
: AD 22 4B 18 FF 72 88 F3 C5 77 B0 CF 88 5C F4 19
: [ Another 129 bytes skipped ]
289 3: INTEGER 65537
: }
: }
: }
0 warnings, 0 errors.
err = PEM_write_RSAPrivateKey(privwriter, key, EVP_des_ede3_cbc(),
(unsigned char*)password.c_str(),
password.size(), NULL, NULL);
I believe the OpenSSL folks recommend you use PEM_write_PKCS8PrivateKey. See PEM(3) and pkcs8(1).
Now I want to try these to make sure I haven't got anything wrong but it wont' load:
$ openssl rsautl -encrypt -inkey key.pub -pubin -in data.txt -out enc.txt
You can understand the behavior by looking at <openssl src>/apps/rsautl.c. Here are the relevant lines:
else if (!strcmp(*argv, "-pubin")) {
key_type = KEY_PUBKEY;
}
...
case KEY_PUBKEY:
pkey = load_pubkey(bio_err, keyfile, keyform, 0, NULL, e, "Public Key");
break;
...
Then, in apps.c:
if (format == FORMAT_ASN1) {
pkey = d2i_PUBKEY_bio(key, NULL);
}
...
else if (format == FORMAT_PEM) {
pkey = PEM_read_bio_PUBKEY(key, NULL, ...);
}
...
The observation above is the routines are using *_PUBKEY.
There's also a code path based on format == FORMAT_PEMRSA that calls PEM_read_bio_RSAPublicKey, but I don't know how to trigger it. Looking at rsautl(1), I don't think you can because there's no switch that exposes it.
If it was going to trigger, it would be based on a combination of the -keyform option combined with format == FORMAT_PEMRSA. But apps.c's str2fmt does not return a FORMAT_PEMRSA.
I think that means your only option is to use a SubjectPublicKeyInfo. And that means using PEM_write_PUBKEY (or convert the key after the fact).
Now related: OpenSSL Bug Report, Issue 3887: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails.
I faced the same problem and managed to debug by following #jww answer above. In the process I discover a simple command that does not require a EVP_PKEY.
Just use PEM_write_bio_RSA_PUBKEY(BIO * bp, RSA * x) directly. Read PEM_write documentation for details.
Where can i find some documentation on the format of an RSA public key?
An RSA public key formatted by OpenSSH:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYsc8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7rNzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaXfgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQLGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
The same public key formatted for use in Secure Shell (RFC 4716 - The Secure Shell (SSH) Public Key File Format):
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYs
c8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS
0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7r
NzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaX
fgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQ
LGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
---- END SSH2 PUBLIC KEY ----
The same public key formatted as an RSA public key (note the five -, and no space):
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA+xGZ/wcz9ugFpP07Nspo6U17l0YhFiFpxxU4pTk3Lifz9R3zsIsu
ERwta7+fWIfxOo208ett/jhskiVodSEt3QBGh4XBipyWopKwZ93HHaDVZAALi/2A
+xTBtWdEo7XGUujKDvC2/aZKukfjpOiUI8AhLAfjmlcD/UZ1QPh0mHsglRNCmpCw
mwSXA9VNmhz+PiB+Dml4WWnKW/VHo2ujTXxq7+efMU4H2fny3Se3KYOsFPFGZ1TN
QSYlFuShWrHPtiLmUdPoP6CV2mML1tk+l7DIIqXrQhLUKDACeM5roMx0kLhUWB8P
+0uj1CNlNN4JRZlC7xFfqiMbFRU9Z4N6YwIDAQAB
-----END RSA PUBLIC KEY-----
The hex dump of the base-64 encoded data:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25 00 00 01 00 7f 9c 09
8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f d9 89 f0 33 df ee 50 6d 5d d0
16 2c 73 cf ed 46 dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9 cb
f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32 70 e6 b5 f3 10 4a f5 c3
96 99 c2 92 d0 0f 05 60 1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19
a1 90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d 3f 7d 4a eb d2 dc
42 0c 48 b2 5e eb 37 3c 6c a0 e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38
84 a0 bb d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b ad f0 75 59
3e ac df cd fc 48 46 97 7e 06 6f 2d e7 f5 60 1d b1 99 f8 5b 4f d3 97
14 4d c5 5e f8 76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1 fb c8
f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f 5c b9 5f fa e9 35 93 65 59
6d be 8c 62 31 a9 9b 60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
i've read that there are a couple of formats🕗:
Key data may be encoded in three general ways:
Binary DER-encoded format. This is sometimes called ASN.1 BER-encoded
PEM or base64 format. This is the same data as the DER-encoded file but it is encoded in base64 with additional header and footer lines
XML format.
If it's ASN.1, the hex certainly doesn't look like it.
What's the format of an RSA public key?
See also
RSA Key Formats
Abstract Syntax Notation One
Convert Base64 Public Key to XML Signature 🕗
Decode PEM formats
You can't just change the delimiters from ---- BEGIN SSH2 PUBLIC KEY ---- to -----BEGIN RSA PUBLIC KEY----- and expect that it will be sufficient to convert from one format to another (which is what you've done in your example).
This article has a good explanation about both formats.
What you get in an RSA PUBLIC KEY is closer to the content of a PUBLIC KEY, but you need to offset the start of your ASN.1 structure to reflect the fact that PUBLIC KEY also has an indicator saying which type of key it is (see RFC 3447). You can see this using openssl asn1parse and -strparse 19, as described in this answer.
EDIT: Following your edit, your can get the details of your RSA PUBLIC KEY structure using grep -v -- ----- | tr -d '\n' | base64 -d | openssl asn1parse -inform DER:
0:d=0 hl=4 l= 266 cons: SEQUENCE
4:d=1 hl=4 l= 257 prim: INTEGER :FB1199FF0733F6E805A4FD3B36CA68E94D7B974621162169C71538A539372E27F3F51DF3B08B2E111C2D6BBF9F5887F13A8DB4F1EB6DFE386C92256875212DDD00468785C18A9C96A292B067DDC71DA0D564000B8BFD80FB14C1B56744A3B5C652E8CA0EF0B6FDA64ABA47E3A4E89423C0212C07E39A5703FD467540F874987B209513429A90B09B049703D54D9A1CFE3E207E0E69785969CA5BF547A36BA34D7C6AEFE79F314E07D9F9F2DD27B72983AC14F1466754CD41262516E4A15AB1CFB622E651D3E83FA095DA630BD6D93E97B0C822A5EB4212D428300278CE6BA0CC7490B854581F0FFB4BA3D4236534DE09459942EF115FAA231B15153D67837A63
265:d=1 hl=2 l= 3 prim: INTEGER :010001
To decode the SSH key format, you need to use the data format specification in RFC 4251 too, in conjunction with RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
For example, at the beginning, you get 00 00 00 07 73 73 68 2d 72 73 61. The first four bytes (00 00 00 07) give you the length. The rest is the string itself: 73=s, 68=h, ... -> 73 73 68 2d 72 73 61=ssh-rsa, followed by the exponent of length 1 (00 00 00 01 25) and the modulus of length 256 (00 00 01 00 7f ...).
Starting from the decoded base64 data of an OpenSSL rsa-ssh Key, i've been able to guess a format:
00 00 00 07: four byte length prefix (7 bytes)
73 73 68 2d 72 73 61: "ssh-rsa"
00 00 00 01: four byte length prefix (1 byte)
25: RSA Exponent (e): 25
00 00 01 00: four byte length prefix (256 bytes)
RSA Modulus (n):
7f 9c 09 8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f
d9 89 f0 33 df ee 50 6d 5d d0 16 2c 73 cf ed 46
dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9
cb f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32
70 e6 b5 f3 10 4a f5 c3 96 99 c2 92 d0 0f 05 60
1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19 a1
90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d
3f 7d 4a eb d2 dc 42 0c 48 b2 5e eb 37 3c 6c a0
e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38 84 a0 bb
d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b
ad f0 75 59 3e ac df cd fc 48 46 97 7e 06 6f 2d
e7 f5 60 1d b1 99 f8 5b 4f d3 97 14 4d c5 5e f8
76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1
fb c8 f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f
5c b9 5f fa e9 35 93 65 59 6d be 8c 62 31 a9 9b
60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
The closest validation of my theory i can find it from RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the 'e' and 'n' parameters form the signature key blob.
But it doesn't explain the length prefixes.
Taking the random RSA PUBLIC KEY i found (in the question), and decoding the base64 into hex:
30 82 01 0a 02 82 01 01 00 fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
63 02 03 01 00 01
From RFC3447 - Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1:
A.1.1 RSA public key syntax
An RSA public key should be represented with the ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
The fields of type RSAPublicKey have the following meanings:
modulus is the RSA modulus n.
publicExponent is the RSA public exponent e.
Using Microsoft's excellent (and the only real) ASN.1 documentation:
30 82 01 0a ;SEQUENCE (0x010A bytes: 266 bytes)
| 02 82 01 01 ;INTEGER (0x0101 bytes: 257 bytes)
| | 00 ;leading zero because high-bit, but number is positive
| | fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
| | e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
| | 11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
| | dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
| | fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
| | 23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
| | 9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
| | 4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
| | 41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
| | 97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
| | fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
| | 63
| 02 03 ;INTEGER (3 bytes)
| 01 00 01
giving the public key modulus and exponent:
modulus = 0xfb1199ff0733f6e805a4fd3b36ca68...837a63
exponent = 65,537
Update: My expanded form of this answer in another question
Reference Decoder of CRL,CRT,CSR,NEW CSR,PRIVATE KEY, PUBLIC KEY,RSA,RSA Public Key Parser
RSA Public Key
-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----
Encrypted Private Key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
-----END RSA PRIVATE KEY-----
CRL
-----BEGIN X509 CRL-----
-----END X509 CRL-----
CRT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
CSR
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
NEW CSR
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----
PEM
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
PKCS7
-----BEGIN PKCS7-----
-----END PKCS7-----
PRIVATE KEY
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
DSA KEY
-----BEGIN DSA PRIVATE KEY-----
-----END DSA PRIVATE KEY-----
Elliptic Curve
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
PGP Private Key
-----BEGIN PGP PRIVATE KEY BLOCK-----
-----END PGP PRIVATE KEY BLOCK-----
PGP Public Key
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----
In wireshark, I am able to see the encrypted data to and fro from my PC. It does not use diffie hellman algorihm for key exchange because I see only the Client Key Exchange packet but there is no Server Key Exchange packet. That means the browser is sending the encrypted key to the server(encrypted using the server's public key).
But I do not see any encrypted data in that packet("Client Key Exchange"). How to view the encrypted key?
You won't see the encrypted shared-key, it's not exchanged. You can see the encrypted pre-master secret when using RSA authenticated key exchange. (Note that using Ephemeral Diffie-Hellman isn't the only reason for not seeing a server key exchange message: it could also use a DH_DSS or DH_RSA cipher suite, but this is unusual as far as I know).
If you follow the instructions about decrypting SSL with Wireshark, use the "SSL debug file" option to store the logs into a file. (Note that the user interface has changed slightly in newer versions of Wireshark, in the way you configure the private key.)
The log files will contain the pre-master secret and the shared keys.
(By the way, you need the server's private key to do this, of course.)
Using the sample data provided on the Wireshark page, you get:
pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32
pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8
master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb
key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef
35 70 5e ad 21 22 3e f6
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f
47 71 95 71
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6
Until recently the dissection of the ClientKeyExchange was like this(version 1.6 and below):
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
But if you use this verison(1.7.2 upwards) the key dissection will be like this:
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
RSA Encrypted PreMaster Secret
Encrypted PreMaster length: 128
Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346
You can see the encrypted pre-master:)
Awesome write up here explaining how SSL works, notice at no time during this handshake is the private key ever sent over the wire.
http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/
Long story short there is no way to decrypt SSL streams without the server's private key (unless you work for the NSA or something), however you may want to look into getting in between the server and client during the handshake and if the user does not check the validity of the certificate that is presented you are in business.
Here is a tool that can do that for you among many others
http://mitmproxy.org/
Of note I highly recommend the sans reading room article on SSL Mitm(Man in the Middle) attacks.