Documentation

How AIProxy works

To use AIProxy you first add the service/API you want to protect, then add your API key through our dashboard. We don't actually store the key on our servers, we encrypt the key and store 1/2 of that result in our backend and give the customer the other 1/2 to send up with requests to AIProxy. We marry the two pieces and decrypt the key, forwarding that onto the API.

This technique addresses a few security concerns:

1. If someone sniffs the customer's AIProxy request from the network, there is no way for the attacker to use the information in the request headers to derive the customer's secret key. Anything that goes over the network is fair game for an attacker to view in plaintext. E.g. an attacker could install your iOS app on their own phone and then MITM themselves to inspect network requests of your app. So we assume someone is looking, and take precaution that the data that they see is as useless as possible.
2. By splitting the encrypted key into two parts, and storing them separately (one on the backend, and one in your iOS app), we disincentivize attacks on AIProxy itself. The alternative, where our database has all the information it needs to construct secret keys, would make for a lucrative target for attackers. If someone were able to get in, they could get a whole bunch of secret keys.
3. It gives customers the assurance that no one within AIProxy can look at their secret keys, because we don't actually have them in our database.

That's one piece of protection, and prevents anyone from sniffing your API key from your Mac or iOS app completely. However, an attacker can still grab your AIProxy headers and abuse your AIProxy endpoint. So to combat that we send up 1 time use DeviceCheck tokens. We check the DeviceCheck token against Apple's servers to ensure that it's from a legit device running your app, and also check against our DB to make sure the token hasn't been used before. If the token passes both of those checks then we fulfill the request.