Re: [Iotsi] IoT Security

["Smith, Ned" <[e-mail]>]

Thanks Russ!

A short summary of options for protecting data end-to-end given an
expectation of data translation are the following (where T refers to the
translation node, S refers to the source / sender, R refers to the
recipient, D refers to the domain in which S, R and T may be trusted, D[x]
is notation describing the domain in which 'x' is trusted, D[S] refers to
the domain in which S is trusted, D[R] refers to the domain in which R is
trusted, D[SR] refers to a domain in which both S and R are trusted.

Options for end-end trust involve construction of a system involving S, R
and T; and where STR represents end-to-end interoperation and D[STR]
represents end-to-end trust according to the domain D.

Option 1) Reference - D[STR] - The reference case is where STR are in the
same domain implying security and privacy is uniformly applied across the
three endpoints. 

Option 2) Equivalence - (a) D[ST] = D[R], (b) D[S] = D[TR], (c) D[ST] =
D[TR], (d) D[S] = D[T] = D[R];  where "=" means security policies and
enforcement mechanisms are the same across disparate domains. There are 4
sub cases, where translation is applied in one of the respective domains
of  S, R or T. This is acceptable because the security policies and
enforcement are equivalent. However, R may require attestation from D(ST)
as a basis for allowing the deployment option.

Option 3) Federation - (a) D[ST] ~= D[R], (b) D[S] ~= D[TR], (c) D[ST] ~=
D[TR], (d) D[S] ~= D[T] ~= D[R]; where "~=" means security policies and
enforcement mechanisms are approximately equal based on a trust mapping
between D[S], D[R] and D[T].

Option 4) Mutation - (a) D[ST] ~ D[R], (b) D[S] ~ D[TR], (c) D[ST] ~
D[TR], (d) D[S] ~ D[T] ~ D[R]; where "~" means security policies and
enforcement mechanisms are dissimilar and data are manipulated
(aggregated, filtered, modified) to achieve a security or privacy
objective prior to disclosure to the recipient.

All options presume the identities of S, R and T are authenticated.

I chose these names haphazardly; I'm open to renaming them if there is
naming dissonance. 

It may be appropriate to consider hybrid cases involving D[T] where the
D[S] <--> D[T] relationship differs from the D[T] <--> D[R] relationship.

There are techniques where trust equivalence can be established that is
agreeable to both S and R. For example, ARM TrustZone is a trusted
execution environment (TEE) that may be sufficiently constrained and
hardened that the code to perform T can be vetted by both S and R when
loaded into the TEE.

Data translation case (c) may be less intuitive. It is asserting there may
be an intermediate representation of the data that is more desirable for
mapping to the target data representation. An intermediate representation
may be used to improve the range of possible R recipients or to improve
security / privacy properties given S may have less control over the data
once it leaves D(S).
 

Ned Smith
Principal IoT Security Architect
Intel SSG-OTC
[e-mail]
+1.503.712.3695




On 3/22/16, 8:04 AM, "Iotsi on behalf of Russ Housley"
<[e-mail] on behalf of [e-mail]> wrote:

>At the workshop we talked about gateways that translate the syntax while
>preserving the semantics.  It was very clear how one might provide
>confidentiality and integrity for connections to the gateway, but no one
>had any suggestions for end-to-end confidentiality or integrity.  As
>requested at the workshop, I am starting this tread to resume that
>discussion.
>
>Russ
>
>_______________________________________________
>Iotsi mailing list
>[e-mail]
>https://www.iab.org/mailman/listinfo/iotsi