Hi,
I'm writing a small application that takes an Ethernet frame (straight
from the kernel) and parses the SNMP data included within against a
set of rules to determine if the packet should be forwarded or
dropped. The application is for a small embedded gateway that sits
between the agent and client.
So far I have been able to parse all the relevant data up to the
security parameters but when it comes to decrypting the AES-encrypted
pdu data using the privacy parameters, I am stumped. Whatever I print
out is garbage (I check my results against wireshark's results). Below
is the section of code that is supposed to do the decryption:
// decrypt
static int snmp_pdu_decrypt(struct snmp_pdu * data)
{
unsigned char key[] = "some16bytepasswd";
unsigned char iv[128];
int boot, engine, num = 0;
AES_KEY aeskey;
memset(iv, 0, sizeof(iv));
boot = htonl(data->msg_engine_boots);
engine = htonl(data->msg_engine_time);
// construct IV
memcpy(&iv[0], &boot, 4);
memcpy(&iv[4], &engine, 4);
memcpy(&iv[8], data->msg_priv_params, 8);
// set the key
(void) AES_set_encrypt_key(key, 16 * 8, &aeskey);
AES_cfb128_encrypt(data->msg_enc_data, data->msg_data,
data->msg_enc_data_len, &aeskey, iv, &num, AES_DECRYPT);
data->msg_data_len = data->msg_enc_data_len;
memset(iv, 0, 128);
return 1;
}
Regarding the above:
- data->msg_engine_{boots,time} are both unsigned integers that have
been converted to host byte format previously.
- RFC 3826 requires the boot time in MSB as the first 4 octets, engine
time in MSB as the next 4 octets, and the privacy params as the last 8
octets. I'm hoping that's how the IV is constructed above.
- I am NOT authenticating the packet. I'm not sure if this changes the
encrypted PDU in any shape or form.
- I have played with the byte order of both boot and engine to no
avail. I think the problem is elsewhere.
- The code above is similar to what is in scapi.c, with the exception
of the IV construction.
---
Here is the packet dump (minus IP headers):
30 81 81 02 01 03
30 0f 02 02 68 15 02 03 00 ff e3 04 01 07 02 01
03 04 39 30 37 04 0d 80 00 1f 88 80 7a 89 9b 48
4b 90 f4 45 02 01 01 02 02 00 ac 04 07 64 65 66
61 75 6c 74 04 0c b3 58 4d ed 46 14 5a 11 e6 91
5d 9c 04 08 79 b4 ba b1 bf e8 45 4d 04 30 33 1c
03 40 1a bf ee 66 90 4d 1a 40 ad 10 33 0f b2 8e
8c 73 88 20 98 64 63 0d 7d ac a9 9e 99 d4 c9 d6
39 78 2a cf aa b5 b6 7d cc 6e b8 9b d3 6c
----
And my translated version:
pdu size: 129
msg ver: 3
msg id: 26645
msg max size: 65507
msg flags: 7
msg sec model: 3
msg engine id: 80 00 1F 88 80 7A 89 9B 48 4B 90 F4 45
msg engine boots: 1
msg engine time: 172
msg priv params: 79 B4 BA B1 BF E8 45 4D
enc data (48):
33 1C 03 40 1A BF EE 66 90 4D 1A 40 AD 10 33 0F B2 8E 8C 73 88 20 98
64 63 0D 7D AC A9 9E 99 D4 C9 D6 39 78 2A CF AA B5 B6 7D CC 6E B8 9B
D3 6C
data (48):
1D 4C 8C 73 6E 8A 45 65 2E 0E BE 6B F3 3C 49 95 B9 A0 F5 E5 AE 56 EE
37 EA D8 F7 CF 6A 03 AB 1F 8F 9E 8C A3 44 CF 3F 06 50 02 FC BB C4 74
EF 6B
---
And wireshark's portion of the decrypted PDU:
30 2e 04 0d 80 00 1f 88 80 7a 89 9b 48 4b 90 f4
45 04 00 a1 1b 02 02 20 8f 02 01 00 02 01 00 30
0f 30 0d 06 09 2b 06 01 04 01 82 22 06 14 05 00
--
This is the IV according to GDB:
0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xac
0x79 0xb4 0xba 0xb1 0xbf 0xe8 0x45 0x4d
Note that everything up to the encrypted PDU scope matches. The
decrypted portion does not. Also, the password above has been changed
from the original; if you require the original password, please let me
know.
I hope someone would be able to give me some insight as to what I am
doing wrong.
Thanks.
- Shez
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
