Suppose the attacker knows [some part of the plaintext]
Does this reveal information that could lead to a security exploit
Given the rest of your notes, that you're using CBC mode (and depending on how you manage the IV), then yes, it can allow the attacker to modify messages such that the attacker can control the decrypted plaintext. For instance, an attacker could likely modify {"d":{"status":"success"}} to {"X":{"status":"success"}}. This could be a significant exploit or not.
(the attacker finding the key)?
Not directly. That isn't computable, even if you know the full plaintext and ciphertext. While the math is slightly different, this is similar to the problem of coming up with a plaintext that generates a given SHA-256 hash. AES is intended to make this computation no more efficient than a brute-force search.
However, if you are using a password to generate the key, and your KDF is incorrect, then there are definitely very good attacks against the password, and through it, the key. Knowing things about your data format will make these attacks faster (and if you fail to create a proper IV, they will be even faster). There are a lot of little pieces to correct AES encryption. If you get any of them wrong, then all the "AES is unbreakable" claims go out the window. Properly Encrypting With AES With CommonCrypto covers the main issues. They are the same for .NET as they are for ObjC.
If so, what would prevent this?
To the initial problem (data integrity / authentication), as Simon Johnson says, ideally use an authenticated mode such as CCM or GCM rather than CBC.
Alternately, if you do not have an authenticated mode available, use an HMAC to authenticate your data and demonstrate that it has not been modified. I would recommend draft-mcgrew-aead-aes-cbc-hmac-sha2 as a good approach to this. RNCryptor is similar and designed to address this issue, but there is not yet a C# implementation. (If you are interested in this problem, it is very easy to implement the RNCryptor data format in C#, and I'd be happy to work with you to build an open source version.)
If there is no security risk, what property of encryption prevents it from being an issue?
Let us consider the more basic version of this question. Get rid of block cipher modes, IVs, authentication, etc. Let's get back down to just AES. All AES does is transform 16 bytes into a different 16 bytes.
Encrypting with a key K and plaintext P yields a ciphertext C.
E(K, P) = C
For AES, there exists an efficient inverse of E called D such that:
D(K, C) = P
This just says that it is possible to encrypt something with a key, and then decrypt it with the same key. I.e.:
D(K, E(K, P)) = P
What you're asking for is some efficient function X such that:
X(P, C) = K
There are many functions E and D for which an efficient X exists. For example, if E is the xor function, then D is also the xor function and X interestingly enough is also the xor function. However, the AES function is such that there is no known efficient X (I don't believe that this is currently proven, but we certainly do not know what that X is).
This is a very long-winded way of saying that there is no known Known-plaintext attack on AES.
(I'm making a somewhat sloppy and broad claim here. There are some known attacks against AES that are not related to known-plaintext. There is a known attack that can recover an AES-128 key in complexity 2^126.1, which for cryptographers is a really powerful finding, but for most common uses is not a major concern.)
