Subject: Re: [T2TRG] D2D security and privacy

From: Aaron Yi DING <[email-masked]>
Date: Wed, 11 Jan 2017 10:12:51 +0100

Hi Dirk,

Thanks a lot for your feedback! I like the example you gave for non-repudiation. 

I am now discussing with corresponding authors to update it and include your suggestions, i.e., authentication authorization mixing, non-repudiation and confidentiality.

Cheers,
Aaron

On 11/01/17 09:18, "icnrg on behalf of Dirk Kutscher" <[email-masked] on behalf of [email-masked]> wrote:

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:

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: Aaron Yi DING <[email-masked]>
Date: Wed, 11 Jan 2017 12:25:13 +0100

Hi,

Your suggestions have been included. Here is the latest one:
https://www.cs.helsinki.fi/u/yding/publications/d2d-pre-camera.pdf

including Sec II.a, Table II, Figure 2,  Figure 3 and Acknowledgement.

Thanks,
Aaron

On 11/01/17 10:12, "Aaron Yi DING" <[email-masked]> wrote:

Hi Dirk,

Cheers,
Aaron

Hi Aaron,

Best regards,
Dirk

Hi,

Cheers,
Aaron

Cheers,
Aaron

---

From: Aaron Yi DING <[email-masked]>
Date: Wed, 11 Jan 2017 20:22:21 +0100

Hi Marc, Eliot, Carsten,

Thanks for your feedback. I will try to incorporate them. 

Cheers,
Aaron

On 11/01/17 18:17, "T2TRG on behalf of Carsten Bormann" <[email-masked] on behalf of [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

On 11/01/17 18:07, "Eliot Lear" <[email-masked]> wrote:
On 1/11/17 8:40 AM, [email-masked] wrote:
> 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

On 11/01/17 17:40, "[email-masked] on behalf of [email-masked]" <[email-masked] on behalf of [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.

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]> wrote:

Hi Aaron,

* 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

Cheers,
Aaron