Android device/account specific ID for encryption seed

This may be a loaded questions which has been asked in multiple forms before, but I haven't seen it asked quite this way, and I'd like some opinions on how to proceed.

I'm developing an application which requires storing credentials to third-party web services on the device. I want these开发者_运维百科 credentials to be encrypted, but I also don't want to store the seed in code/on the device to prevent possible hijacking. The app also supports backing up using Googles cloud backup functionality, further necessitating encryption.

My thought was that if I could find a unique identifier, that could be used as the seed. There are a few odd requirements making this difficult.

1. The ID MUST be the unique AND the same for a given combination of hardware/user in all circumstances.
2. It cannot be simply tied to a device or user, it must be a combinations of both.
3. It must be available NO MATTER WHAT; Wifi and Bluetooth MAC addresses are out of the question, as they are unavailable on some devices when they are turned off.
4. From what I've read, the TelephonyManager IDs (SIM, etc.) aren't available on all devices.
5. From what I've read, the ANDROID_ID won't be present in all circumstances.
6. The app will be released in multiple markets (eg. Amazon Appstore), so a Google account won't necessarily be present.
7. Doing a factory wipe should NOT affect anything used to generate this ID (that way the user can backup, wipe & restore without interruption).
8. Doing an OTA upgrade should NOT affect anything used to generate this ID (see reason above).
9. It is OK if they have to reauthenticate after an uninstall/reinstall.

I understand that this value can obviously be retrieved by other applications, which is why I intend to hash it, further seeded by the applications UID as well as <your suggestion here>.

If anyone feels the requirements are unrealistic, I'd like to hear that as well too.

Especially in light of the recent hacking marathons, I want to be able to at least say "If someone can compromise this, nothing on your phone is safe".

Your requirements are reasonable to ensure security, however as you seem to suspect, they are unrealistic. There are simply too many differences in levels of Android device support to make it realistic.