Subject: [T2TRG] D2D security and privacy

From: Aaron Yi DING <[email-masked]>
Date: Thu, 05 Jan 2017 20:10:39 +0100

Hi,

For T2TRG & ICNRG colleagues, a recent survey on D2D security and privacy:
https://www.cs.helsinki.fi/u/yding/publications/comst2017.html 

pre-camera pdf can be found here if you are interested:
https://www.cs.helsinki.fi/u/yding/publications/d2d-pre-camera.pdf 

Cheers,
Aaron

On 20/11/16 20:23, "Aaron Yi DING" <[email-masked]> wrote:

As presented in the Lisbon meeting, our work on Securebox (for IoT security) will appear at ACM CoNEXT CAN '16
http://conferences2.sigcomm.org/co-next/2016/#!/canprogram 

The pre-print and abstract can be found here for those who are interested:
https://www.cs.helsinki.fi/u/yding/publications/can2016.html

Cheers,
Aaron

--
TU Munich, Connected Mobility
https://www.cm.in.tum.de/index.php?id=25

---

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 11 Jan 2017 09:18:46 +0100

Hi Aaron,

Thanks for sharing. A few comments after a cursory read:

The description of the security and privacy requirements in IIa seems a 
bit sloppy. For example:

- a) Authentication seems to be mixing up authentication and 
authorisation
- c) Non-Repudiation: what you say here may not be wrong, but the 
example with the attacker who wants an innocent party appear as an 
attacker is not the most straightforward one. Non-repudiation is 
guaranteeing that authentication can be asserted to be genuine and not 
be refuted later. So a better example may be a system that prevents an 
attacker who was authenticated before to deny authorship of messages 
later.
- e) Confidentiality: this is about ensuring that only *authorized* 
users can access the confidential information.

Best regards,
Dirk

On 5 Jan 2017, at 20:10, Aaron Yi DING wrote:

> As presented in the Lisbon meeting, our work on Securebox (for IoT 
> security) will appear at ACM CoNEXT CAN '16
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: <[email-masked]>
Date: Wed, 11 Jan 2017 16:40:19 +0000

Aaron,

I would add that non-repudiation is mostly a legal concept not a cryptographic concept.  It is usually broken down to non-repudiation of origin, of transfer, and of delivery.  In a cooperative D2D environment, the biggest problem (as I see it) is if one really trusts another D2D device to attest to some aspect of non-repudiation as collusion attacks might be easy.

In terms of authentication, I would point out that strong authentication requires proof of current possession of the private key — i.e. they have some challenge and response.  Sometimes one works around this by time-limiting messages.  Most ICN applications do not prove current possession of private key, because they sign something without an interactive protocol or 3rd party.  For example, I could intercept a signed message that actuates something (e.g. turns on a light) and save it for later.  Then at a time of my choosing I send the message. If the actuator (e.g. light bulb) does not use some other verification method, it might be fooled to turn on when I want it to, not when the authorized person wants it to (people work around this with sequence numbers, time stamps, message validity periods, etc.).

I would also change the definition of authentication.  It does not verify who you are.  It verifies possession of a private key or a secret.  You need some other mechanism to assign identity to a key or secret, and this is what starts to get messy and requires revocation.  If I lose my private key, then I need to revoke it so it is no longer associated with my identity.  Someone could still authenticate that a message was produced by possession of the key or secret, but that is separate from associating the key with me.

Marc

On Jan 11, 2017, at 3:18 AM, Dirk Kutscher <[email-masked]<mailto:[email-masked]>> wrote:

Hi Aaron,

The description of the security and privacy requirements in IIa seems a bit sloppy. For example:

  *   a) Authentication seems to be mixing up authentication and authorisation
  *   c) Non-Repudiation: what you say here may not be wrong, but the example with the attacker who wants an innocent party appear as an attacker is not the most straightforward one. Non-repudiation is guaranteeing that authentication can be asserted to be genuine and not be refuted later. So a better example may be a system that prevents an attacker who was authenticated before to deny authorship of messages later.
  *   e) Confidentiality: this is about ensuring that only authorized users can access the confidential information.

Best regards,
Dirk

Hi,

Cheers,
Aaron

On 20/11/16 20:23, "Aaron Yi DING" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Aaron

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Jan 2017 09:07:38 -0800

Hi,

On 1/11/17 8:40 AM, [email-masked] wrote:
> Aaron,
>
> I would add that non-repudiation is mostly a legal concept not a
> cryptographic concept.  It is usually broken down to non-repudiation
> of origin, of transfer, and of delivery.  In a cooperative D2D
> environment, the biggest problem (as I see it) is if one really trusts
> another D2D device to attest to some aspect of non-repudiation as
> collusion attacks might be easy.

Yes.  And there is a fundamental problem: what happens when Bob attacks
Alice?  That is- is he is compromised.  What is the role of Faythe?

Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Jan 2017 18:17:27 +0100

On 11 Jan 2017, at 09:18, Dirk Kutscher <[email-masked]> wrote:
> 
> 	• c) Non-Repudiation: what you say here may not be wrong, but the example with the attacker who wants an innocent party appear as an attacker is not the most straightforward one. Non-repudiation is guaranteeing that authentication can be asserted to be genuine and not be refuted later. So a better example may be a system that prevents an attacker who was authenticated before to deny authorship of messages later.

A much better term for what this not so great term is usually really meant to say is “third-party verifiability”.

Note that “accountability” (which is what the joe-job example is about) may or may not require third-party verifiability — in many cases it is very much sufficient that you know who did this to you and there is no need to prove to third parties.

It’s 2017 and we still don’t have agreed names for the basic security objectives and security services.  RFC 4949 notwithstanding...

Grüße, Carsten