AES enc/dec gives on different platforms different outputs for the first 16 bytes - aes

Question

I have a really strange behaviour about encryption and decryption with AES CBC. I use a python script to encrypt a block of data and would like to decrypt it on a microcontroller (TI C2000) and somehow it works, but the first 16 bytes of a 128 byte block are always different on the C2000 and the Python Script and I really don't know how this is possible. Especially it is strange, since the input data in the encryption routine is exactly as expected, since my first tought was, that it must be incorrect input data, but that is not the case.
The block I encrypt/decrypt looks like this:
key[16] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c}
iv[16] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}
data_unencrypted[128] = {0x00,0x00,0x1b,0x00,0x01,0x00,0x00,0x00,0x02,0x00,0x76,0x58,0x08,
0x00,0x10,0x00,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}
data_encrypted_python[128] = {0x2f,0xf2,0x20,0x85,0x2d,0xcd,0xb7,0x5e,0xfe,0x2b,0x90,0xe7,0x66,
0x3e,0xbb,0x3e,0xfa,0x15,0xf1,0xca,0x3e,0xc4,0x92,0x33,0x1a,0xc1,0xea,0x36,0x33,0xc5,0xeb,0xd4,0x33,0x5f,
0xcd,0x06,0x74,0xd4,0x85,0x79,0xed,0xf8,0xdc,0x5e,0x45,0x3d,0x74,0x29,0x63,0x69,0x77,0xc9,0x8b,0xdd,0x09,
0x8b,0xb4,0x2c,0xd7,0xf9,0xe9,0x94,0x1b,0x5d,0x20,0xa4,0x01,0xa7,0x91,0x67,0x24,0xa3,0x78,0xf7,0x72,0x6e,
0xbd,0xd3,0x37,0x27,0x13,0xcd,0x44,0x40,0x35,0x49,0x2d,0xf7,0xdd,0x58,0x35,0xe9,0x1b,0x1d,0x1f,0x97,0xe0,
0xe4,0xc4,0x89,0x0c,0x88,0x46,0x61,0x47,0xbc,0x87,0x3a,0xf5,0x50,0x9b,0xb0,0x4b,0xd9,0x8e,0x05,0x31,0x7c,
0x2a,0xd3,0xb5,0x3b,0xdd,0xa1,0x67,0xc3,0x60,0x39}
--> decrypt in python gives the same as the unencrypted, original data from above.
data_decrypted_c2000[128] = {0x1c,0xc4,0x2b,0xb7,0xd2,0x8d,0x18,0x31,0xe8,0x96,0x30,0x70,0xb5,
0x6a,0xad,0xd3,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}
--> Note, that only the first 16 bytes are false.
How is this possible? Is it even possible without input data corruption?

Answer 1

Yes, it is possible, since CBC uses the previous ciphertext as "vector" for the current block it is trying to decrypt. If a vector is incorrect then the resulting plaintext is also incorrect. However, since the next block only depends on the ciphertext that plaintext error doesn't propagate during decryption.
What is likely happening is that the C2000 uses the wrong - seemingly random - IV value. Like all other vectors this is XOR'ed with the result of the block cipher decrypt resulting in an also randomized plaintext block. If the next plaintext block would have any (small) error then the ciphertext block could have been corrupted, but that's obviously not the case here.
EDIT: After a careful look, I find that the C2000 actually produces the result you would expect given the currently specified IV. That means that the Python IV handling is incorrect, even though it is consistent in both the encryption & decryption functionality.