I would imagine that you could use a "standard" technique (e.g., type
qualifiers w/ data flow) for the immediate problem, assuming that the
adversarial model is something like trusting the programmer and you
just want to make sure they don't accidentally put something that is
high security in a serialized output.

Personally, I thought that there are many apps that do things like
persist auth tokens.  (A few apps I've seen even store passwords..)

Kris

On Tue, Mar 26, 2013 at 2:56 PM, Jeffrey Walton <[email protected]> wrote:
> On Tue, Mar 26, 2013 at 2:04 PM, Kristopher Micinski
> <[email protected]> wrote:
>> I'm not sure I really understand your question.
>>
>> Here's what I think you're saying: Android apps are written to be
>> ephemeral, and routinely get killed (after hey have *hopefully*
>> serialized their state into memory) and restarted at the appropriate
>> points.  But you're worried that the programmer will accidentally
>> serialize some piece of information that they shouldn't be because it
>> is sensitive.  (E.g., this happens with tokens for webservices, for
>> example..)
> Yes. The encrypted secret is the user's password or a session cookie
> that's being cached to improve the UI experience. Persisting an
> encrypted secret across the restart only works if the encryption key
> cannot be recovered; and I can't guarantee that with a Keychain or
> Keystore.
>
> When moving to the background, I recommend wiping secrets if the data
> sensitivity level warrants increased vigilance. That means a user will
> have to, for example, login again on the next relaunch. Its
> inconvenient, but its a necessary evil to comply with some polices.
>
> However, screen rotation is different since I know the application
> will be immediately relaunched. In this case, the "wipe secrets"
> strategy does not really work.
>
> Jeff
>
>> On Tue, Mar 26, 2013 at 1:37 PM, Jeffrey Walton <[email protected]> wrote:
>>> Hi All,
>>>
>>> I'm trying to determine the best way to securely handle state
>>> transitions. Specifically, how to securely persist items such as
>>> Session Keys or Session IDs between restarts due to a device rotation,
>>> language change, etc
>>> (http://developer.android.com/guide/topics/resources/runtime-changes.html).
>>>
>>> Is there a per-restart key available in the onDestroy()/onCreate()
>>> cycle? Note that I don't want to store the secret (or an encryption
>>> key) in a Keychain or Keystore since it can be recovered. I would
>>> prefer something that only lives in memory with a limited lifetime
>>> (the time it takes for the restart).
>>>
>>> What does Android provide at the application level to help ensure
>>> sensitive information is not serialized in plain text across restarts?

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to