Re: [Rum] [EXT] RUM security model

[Paul Kyzivat <[e-mail]>]

I think this discussion highlights the need to first nail down the 
threat model that the providers want to protect against.

James: can you take a crack at that? Possibly pull in some of the other 
providers if you think they will be willing.

(I wonder if providers currently have any sort of robust protection 
against malicious impersonation of their devices? I'm guessing it is 
only security by obscurity.)

	Thanks,
	Paul

On 10/20/20 10:10 AM, Brian Rosen wrote:
> Yes, both apps, one app steals the credential from the other (same machine, same user).
> 
> I also don’t think a downloaded test would be particularly helpful unless we built in a bunch of mechanism that allowed automation of testing.
> 
> And then, what would stop an app from playing nice with a test, and then nasty when it wanted to?
> 
> Both of these exploits do assume that the app developer intends to flaunt approval in some way.  If that’s not a threat that is important to guard against then a simple magic number for an app is enough.  An app gets tested by a provider, and is given a magic number that it provides, securely, in some way.  As long as the providers trust the app developer to not misuse the magic number, it’s an indication that the app (at a particular version presumably) was trusted.
> 
> As long as malicious actors can be ignored, I think we could do something.  I don’t think that is worth much, but if it is, I can write text.
> 
> If you want to protect against malicious actors, then I don’t know how.  TPM won’t work - doesn’t work in Android/iOS.  It’s mostly a PC thing.  Even with TPM, what you need is something like a digest of the code.  You can’t get that.
> 
> Brian
> 
> 
>> On Oct 16, 2020, at 11:17 AM, Paul Kyzivat <[e-mail]> wrote:
>>
>> On 10/15/20 8:24 PM, Brian Rosen wrote:
>>> Nope, it just takes a hacker to create a piece of code that patches an app to look like another app.
>>
>> I don't follow.
>>
>> A user gets a device capable of passing the tests. He requests to enroll it with is provider as one of his devices. As part of that, a test is run between the device and the provider's enrollment server. Then the provider gives the device some sort of cert that can be used when registering.
>>
>> Next, the user decides to try out some other rogue device on his account. Normally he would repeat the above, and the device would fail the test. Instead, he might cause the rogue device to steal the cert from the device that passed. I think he can't help but know he is doing something illicit.
>>
>> I guess if these were both just apps, then a remote attack on the device could install a rogue app that impersonates the valid one and steals its credentials. Is that what you had in mind?
>>
>> Perhaps we need to spend some time with the providers enumerating the attacks they are concerned with.
>>
>> 	Thanks,
>> 	Paul
>>
>>> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat <[e-mail] <mailto:[e-mail]>> wrote:
>>>     On 10/15/20 7:52 PM, Brian Rosen wrote:
>>>      > I don’t think even that would work because there isn’t any way to
>>>     know that the app that was approved is the app that is being used.
>>>     Yes, I guess you are right. But at least it would require the end user
>>>     to enter into a conspiracy with the app developers, and be able to get
>>>     the credential out of one app and into another.
>>>              Thanks,
>>>              Paul
>>>      > What systems like iOS does is rely on the fact that you can’t
>>>     download and run an app that hasn’t been vetted. The code is signed
>>>     and the signature is checked every time the app starts. We don’t
>>>     have an environment like that.  We can’t control what is downloaded
>>>     and we can’t check signatures.
>>>      > I don’t think there is a reliable way to do this. If someone has
>>>     an idea, please explain it, but we can’t be in a “you do something”
>>>     position without a clue as to how.
>>>      >
>>>      > Now, if the app was an iOS app, then the right thing happens.
>>>     There are few other systems that are wired down like that. Android,
>>>     for example, allows you to download and run from arbitrary sites if
>>>     the device is configured to allow that.
>>>      >
>>>      > Brian
>>>      >
>>>      >
>>>      >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>      >>
>>>      >> Eugene,
>>>      >>
>>>      >>> On 10/15/20 3:30 PM, Eugene Christensen wrote:
>>>      >>> Brian,
>>>      >>> Admittedly I do not fully understand certificates and
>>>     authentication but would client certificates or mutual
>>>     authentication with a shared secret work here?
>>>      >>
>>>      >> I'm also not a security expert. To my understanding, the key
>>>     problem is that you want a proof that an implementation has passed
>>>     some sort of test. That is more or less equivalent to having a
>>>     special certification authority that is able to assign a certificate
>>>     based on the passing of a test. But for the system to work that
>>>     certificate needs to be bound to the entity (hw/sw) that passed the
>>>     test. It can't be possible to transfer that certificate to a
>>>     different device.
>>>      >>
>>>      >> A possible alternative would be for each provider to have its
>>>     own test service. When a user gets a new device/application, as part
>>>     of the initial registration of their device with the provider, this
>>>     test would be run. Then the result of that would be granting of
>>>     credentials for that device to access that provider's system.
>>>      >>
>>>      >>     Thanks,
>>>      >>     Paul
>>>      >>
>>>      >>> Thank you.
>>>      >>> Eugene
>>>      >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any
>>>     documents, files or previous e-mail messages attached to it, may
>>>     contain confidential and proprietary information. If you are not the
>>>     intended recipient, or a person responsible for delivering it to the
>>>     intended recipient, you are hereby notified that any disclosure,
>>>     copying, distribution or use of any of the information contained in
>>>     or attached to this message is STRICTLY PROHIBITED. If you have
>>>     received this transmission in error, please immediately notify me by
>>>     reply e-mail at [e-mail]
>>>     <mailto:[e-mail]> <mailto:[e-mail]
>>>     <mailto:[e-mail]>>or by telephone at +1 (801)
>>>     287-9419, and destroy the original transmission and its attachments
>>>     without reading them or saving them to disk.
>>>      >>> *From:* Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>>      >>> *Sent:* Wednesday, September 30, 2020 5:47 PM
>>>      >>> *To:* Eugene Christensen <[e-mail]
>>>     <mailto:[e-mail]>>
>>>      >>> *Cc:* [e-mail] <mailto:[e-mail]>
>>>      >>> *Subject:* Re: [Rum] [EXT] RUM security model
>>>      >>> [EXTERNAL]
>>>      >>> I think we understand why you want it. What we don’t understand
>>>     is what mechanism would provide it. I am generally aware of this
>>>     class of problem and I’m not aware of a solution that will work.  So
>>>     what we need is a suggested mechanism that provides the assurance
>>>     you want that is technically sound.
>>>      >>> Brian
>>>      >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen
>>>     <[e-mail] <mailto:[e-mail]>
>>>     <mailto:[e-mail]
>>>     <mailto:[e-mail]>>> wrote:
>>>      >>>     Thanks for considering how we might implement this security
>>>      >>>     mechanism.  May I add my voice that it is essential that we
>>>     find an
>>>      >>>     option for providing this desired security, whatever it is.  It
>>>      >>>     could be detrimental to the VRS providers to have UAs out
>>>     there,
>>>      >>>     with the ability to register with VRS providers without
>>>     first being
>>>      >>>     fully vetted.  It is our practice anytime we make updates
>>>     to our UAs
>>>      >>>     to test how they work with our UAS before we ever release
>>>     the new UA
>>>      >>>     software into our production environment.  We only want UAs
>>>      >>>     registering that have undergone this rigorous testing with our
>>>      >>>     systems and then only with users which we have awareness of.
>>>      >>>     Thanks,
>>>      >>>     Eugene Christensen
>>>      >>>     CONFIDENTIALITY NOTICE. This e-mail transmission, and any
>>>     documents,
>>>      >>>     files or previous e-mail messages attached to it, may contain
>>>      >>>     confidential and proprietary information. If you are not the
>>>      >>>     intended recipient, or a person responsible for delivering
>>>     it to the
>>>      >>>     intended recipient, you are hereby notified that any
>>>     disclosure,
>>>      >>>     copying, distribution or use of any of the information
>>>     contained in
>>>      >>>     or attached to this message is STRICTLY PROHIBITED. If you have
>>>      >>>     received this transmission in error, please immediately
>>>     notify me by
>>>      >>>     reply e-mail at [e-mail]
>>>     <mailto:[e-mail]>
>>>      >>>     <mailto:[e-mail]
>>>     <mailto:[e-mail]>> or by telephone at +1 (801)
>>>      >>>     287-9419, and destroy the original transmission and its
>>>     attachments
>>>      >>>     without reading them or saving them to disk.
>>>      >>>     --     Rum mailing list
>>>      >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>     <mailto:[e-mail]>>
>>>      >>> https://www.ietf.org/mailman/listinfo/rum
>>>     <https://www.ietf.org/mailman/listinfo/rum>
>>>      >>>     <https://www.ietf.org/mailman/listinfo/rum
>>>     <https://www.ietf.org/mailman/listinfo/rum>>
>>>      >>
>>>      >> --
>>>      >> Rum mailing list
>>>      >> [e-mail] <mailto:[e-mail]>
>>>      >> https://www.ietf.org/mailman/listinfo/rum
>>>     <https://www.ietf.org/mailman/listinfo/rum>
>>
>