Subject: [Panic] notes on Panic Draft

From: Guy Fedorkow <[email-masked]>
Date: Fri, 21 Jul 2017 21:18:57 +0000

Hi Dave, Jessica,
  Thanks for updating the PANIC draft...  I think it's starting to take shape!

  It seems that the next step in moving this forward might be to outline the kind of information we want to retrieve from the endpoints.  I'd assume you'd want some kind of info to identify the device - manufacturer, serial number, etc, plus something that shows the software revision of the relevant modules.  Could that be something like a set of SWID tags?
  It might be good to pattern the device information on IEEE 802.1AR.  Using a cryptographic ID might not be a 'must', but it's probably a desirable option, so making sure it would fit might be helpful.

  It might be good to add a note saying whether the draft should extend to virtualized devices, e.g., NFV instances.  I'd assume that it should, but that might make identity a bit more complicated.

  On the topic of scope, I suppose it might be good to say if "Things", as in IoT, are in scope or not.  I can't guess if that has an impact on the technical spec, but there certainly could be an impact on implied scaling needs, and it might help remind readers that figuring out what's running in the IoT is a getting to be a big problem.

  The diagram in the front of the draft shows an interconnect between Posture Server and Data Store...  seems like there could be some complicated transactions across that link...  Do you think there's existing practice that could be used for this?
  The draft also mentions methods that Endpoints can use to find Posture servers.  I wonder if Zeroconf or some kind of DHCP trick might work for this?

  Finally, in Security Considerations, I wonder if there should be something about how much we do or don't trust the endpoint to report its Information truthfully. The combination of 802.1AR and signed SWID tags might help with a way to assess the reliability of the information.

  Great start, let's try to start breaking down some of the top-level topics to get to the next level of requirements.
Thx,
/guy

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Wed, 26 Jul 2017 14:46:04 -0400

Thanks for the feedback, Guy. Responses in-line. I have more questions than
answers, and I'd like others on the list to weigh in. Looking forward to
hearing from everyone.

On Fri, Jul 21, 2017 at 5:18 PM, Guy Fedorkow <[email-masked]> wrote:

>
>
> Hi Dave, Jessica,
>
>   Thanks for updating the PANIC draft…  I think it’s starting to take
> shape!
>
>
>
>   It seems that the next step in moving this forward might be to outline
> the kind of information we want to retrieve from the endpoints.  I’d assume
> you’d want some kind of info to identify the device – manufacturer, serial
> number, etc, plus something that shows the software revision of the
> relevant modules.  Could that be something like a set of SWID tags?
>

​Personally, I would be delighted if software load could be captured in a
SWID tag. Failing that, I would like to be able to collect a swid-like set
of information from​ the network device. I took a look at NISTIR 8060
(which you can read here: http://nvlpubs.nist.gov/
nistpubs/ir/2016/NIST.IR.8060.pdf) and it looks like-- ignoring data about
the tag itself, like tagID, entity information about the tag creator, etc--
 required fields for a primary tag are:

   - software name and
   - software version,

which should be easy enough to collect on their own.

But, SWID tags offer additional information that could be useful to us.
Evidence and payload fields, for instance, can be used to communicate file
hashes that comprise the software. Tag signatures could allow us to have
move trust in the entity that created the tag (for example, a tag from the
software vendor is potentially more trust worthy than one created by a
third party). And SWIDs allow us to easily communicate what patches are
installed on the product, which is necessary for vulnerability and
compliance assessments.

All things considered, I'd like to use SWID tags. I would like a sense of
how widely implemented they are for network device software and operating
systems. Anyone have any insight there?

  It might be good to pattern the device information on IEEE 802.1AR.
> Using a cryptographic ID might not be a ‘must’, but it’s probably a
> desirable option, so making sure it would fit might be helpful.
>

802.1ar requires installation ​
​of an IDevID, from which many LDevIDs can be created. I'm happy to geek
out on the added security of cryptographic IDs, but, can we talk though the
workflow of getting the initial IDevID installed (who would be responsible
for that? Do network equipment vendors use IDevIDs today? If not, could the
device owner install one without a lot of hassle?)​.

Also, secure though 802.1ar is, it often has no relation to any observable
device identities on the network. I'm thinking about a behavior monitoring
use case here, in which I notice a device behaving in an unexpected manner,
and want to investigate it's posture while I figure out what is going on.
Is there a way to gather many identities from an network device using
netconf/yang?

>
>   It might be good to add a note saying whether the draft should extend to
> virtualized devices, e.g., NFV instances.  I’d assume that it should, but
> that might make identity a bit more complicated.
>

​In section 3 of the draft, we say "​Virtualized network functions are
currently considered in scope". Of course, I worded it that way because I,
too, am concerned about whether their inclusion makes our solution overly
complicated. Are there any netconf experts that can speak to this concern?

>
>
>   On the topic of scope, I suppose it might be good to say if “Things”, as
> in IoT, are in scope or not.  I can’t guess if that has an impact on the
> technical spec, but there certainly could be an impact on implied scaling
> needs, and it might help remind readers that figuring out what’s running in
> the IoT is a getting to be a big problem.
>

​Agreed that IoT is a problem. Do many "Things" that compose the Internet
of Things implement netconf?​ It's such a broad space, I worry that some
"Things" could handle netconf, and others (things like "smart dust", etc.)
couldn't handle the added weight.

>
>   The diagram in the front of the draft shows an interconnect between
> Posture Server and Data Store…  seems like there could be some complicated
> transactions across that link…  Do you think there’s existing practice that
> could be used for this?
>

​Sadly, I know of nothing we could easily point to and say "that is the
protocol we will use for server-datastore communication". But, what I do
not know could fill volumes. Maybe others have ideas where we can start?
​

>   The draft also mentions methods that Endpoints can use to find Posture
> servers.  I wonder if Zeroconf or some kind of DHCP trick might work for
> this?
>

​Zeroconf is an option. TCG has some prior art here (
https://www.trustedcomputinggroup.org/wp-content/uploads/Server_Discovery_And_Validation_v1_0r19-PUBLIC-REVIEW.pdf).
I am happy to consider all viable options.​

>
>   Finally, in Security Considerations, I wonder if there should be
> something about how much we do or don’t trust the endpoint to report its
> Information truthfully. The combination of 802.1AR and signed SWID tags
> might help with a way to assess the reliability of the information.
>

​Agreed, I will add that to the next revision. ​

>
>
>   Great start, let’s try to start breaking down some of the top-level
> topics to get to the next level of requirements.
>
> Thx,
>
> /guy
>
>
>
>
>
> _______________________________________________
> Panic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/panic
>
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 26 Jul 2017 20:55:37 +0000

Hi everyone.

It's really good to see additional interest in this subject area! I
encourage you to review the existing ongoing work in the SACM working group
- specifically the requirements draft (hopefully through IESG soon; see
[1]), one of the drafts under adoption consideration (Endpoint Compliance
Profile: draft-haynes-sacm-ecp) [2], and a data model proposal for carrying
SACM statements (YANG subscribed notifications via SACM Statements:
draft-birkholz-sacm-yang-content; see [3]).

After a successful hackathon in Prague, we are redoubling our efforts on
several of the topics with which PANIC appears to be concerned.  While not
all of the work PANIC may imply should necessarily be done in the SACM
group, I would suggest that those of us interested in PANIC look toward
current working group drafts as well as those being considered for adoption
as potentially viable approaches to the PANIC problem.

Our SACM-related hackathon efforts are mostly documented at [4]. (Note that
there were two SACM-related efforts, though only one was exclusive to
SACM.) We have designs for the next hackathon to integrate these two
related efforts (which may help answer the question about the link between
posture server and data store), which could look something like the diagram
at the bottom of that page (also at [5]).

Of course, there may be little-to-no overlap between what SACM has been
attempting to accomplish and what PANIC would like to ultimately achieve.

Kind regards,

Adam

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/
[2] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/
[3] https://datatracker.ietf.org/doc/draft-birkholz-sacm-yang-content/
[4]
https://github.com/sacmwg/vulnerability-scenario/tree/master/ietf_99_hackathon

[5]
https://raw.githubusercontent.com/sacmwg/vulnerability-scenario/master/ietf_99_hackathon/graphics/hackathon_deployment_combined.png

On Wed, Jul 26, 2017 at 1:46 PM Jessica Fitzgerald-McKay <[email-masked]>
wrote:

> Thanks for the feedback, Guy. Responses in-line. I have more questions
> than answers, and I'd like others on the list to weigh in. Looking forward
> to hearing from everyone.
>
>
> (which you can read here:
> http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf) and it looks
> like-- ignoring data about the tag itself, like tagID, entity information
> about the tag creator, etc--  required fields for a primary tag are:
>
>    - software name and
>    - software version,
>
>>   It might be good to add a note saying whether the draft should extend
>> to virtualized devices, e.g., NFV instances.  I’d assume that it should,
>> but that might make identity a bit more complicated.
>>
>
>>   On the topic of scope, I suppose it might be good to say if “Things”,
>> as in IoT, are in scope or not.  I can’t guess if that has an impact on the

---

From: Guy Fedorkow <[email-masked]>
Date: Thu, 27 Jul 2017 15:01:08 +0000

Hi Jessica,
  You asked about 802.1AR and IDevID.
  I’m sure it’s too early to make 802.1AR IDevID a “must”…  the idea is simple enough, but as you say, the workflow is not.  But I do think we should consider how it would fit.
  I think the simplest way to take advantage of a DevID might simply be to use it to authenticate a TLS session to the device, and use that session to carry the rest of the management protocol.
  You asked about the workflow for installing DevID

-          I think the ‘initial’ IDevID has to be installed by the device manufacturer.   There are various plans, depending on privacy concerns, but I think they all depend on the authority of the manufacturer to certify their own devices.

-          The ‘local’ LDevID can use the manufacturer’s IDevID as a trust anchor, but doesn’t have to.  Anyone can make an LDevID with whatever rules they think are appropriate.
  The workflow that could be used for creating DevIDs for TPM1.2 is described in a TCG doc Subject Key Attestation Evidence, and the version for TPM2.0 is under consideration now at TCG.

  As to Things…  I know about relatively large Things, and those obviously run all these protocols.  But we will have to seek new experts to help us see what Small Things can do.

  Thanks
/guy

From: Jessica Fitzgerald-McKay [mailto:[email-masked]]
Sent: Wednesday, July 26, 2017 2:46 PM
To: Guy Fedorkow <[email-masked]>
Cc: [email-masked]
Subject: Re: [Panic] notes on Panic Draft

Thanks for the feedback, Guy. Responses in-line. I have more questions than answers, and I'd like others on the list to weigh in. Looking forward to hearing from everyone.

On Fri, Jul 21, 2017 at 5:18 PM, Guy Fedorkow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave, Jessica,
  Thanks for updating the PANIC draft…  I think it’s starting to take shape!

  It seems that the next step in moving this forward might be to outline the kind of information we want to retrieve from the endpoints.  I’d assume you’d want some kind of info to identify the device – manufacturer, serial number, etc, plus something that shows the software revision of the relevant modules.  Could that be something like a set of SWID tags?

​Personally, I would be delighted if software load could be captured in a SWID tag. Failing that, I would like to be able to collect a swid-like set of information from​ the network device. I took a look at NISTIR 8060 (which you can read here: http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf) and it looks like-- ignoring data about the tag itself, like tagID, entity information about the tag creator, etc--  required fields for a primary tag are:

  *   software name and
  *   software version,

But, SWID tags offer additional information that could be useful to us. Evidence and payload fields, for instance, can be used to communicate file hashes that comprise the software. Tag signatures could allow us to have move trust in the entity that created the tag (for example, a tag from the software vendor is potentially more trust worthy than one created by a third party). And SWIDs allow us to easily communicate what patches are installed on the product, which is necessary for vulnerability and compliance assessments.

All things considered, I'd like to use SWID tags. I would like a sense of how widely implemented they are for network device software and operating systems. Anyone have any insight there?

  It might be good to pattern the device information on IEEE 802.1AR.  Using a cryptographic ID might not be a ‘must’, but it’s probably a desirable option, so making sure it would fit might be helpful.

802.1ar requires installation ​
​of an IDevID, from which many LDevIDs can be created. I'm happy to geek out on the added security of cryptographic IDs, but, can we talk though the workflow of getting the initial IDevID installed (who would be responsible for that? Do network equipment vendors use IDevIDs today? If not, could the device owner install one without a lot of hassle?)​.

Also, secure though 802.1ar is, it often has no relation to any observable device identities on the network. I'm thinking about a behavior monitoring use case here, in which I notice a device behaving in an unexpected manner, and want to investigate it's posture while I figure out what is going on. Is there a way to gather many identities from an network device using netconf/yang?

  It might be good to add a note saying whether the draft should extend to virtualized devices, e.g., NFV instances.  I’d assume that it should, but that might make identity a bit more complicated.

​In section 3 of the draft, we say "​Virtualized network functions are currently considered in scope". Of course, I worded it that way because I, too, am concerned about whether their inclusion makes our solution overly complicated. Are there any netconf experts that can speak to this concern?

  On the topic of scope, I suppose it might be good to say if “Things”, as in IoT, are in scope or not.  I can’t guess if that has an impact on the technical spec, but there certainly could be an impact on implied scaling needs, and it might help remind readers that figuring out what’s running in the IoT is a getting to be a big problem.

​Agreed that IoT is a problem. Do many "Things" that compose the Internet of Things implement netconf?​ It's such a broad space, I worry that some "Things" could handle netconf, and others (things like "smart dust", etc.) couldn't handle the added weight.

  The diagram in the front of the draft shows an interconnect between Posture Server and Data Store…  seems like there could be some complicated transactions across that link…  Do you think there’s existing practice that could be used for this?

​Sadly, I know of nothing we could easily point to and say "that is the protocol we will use for server-datastore communication". But, what I do not know could fill volumes. Maybe others have ideas where we can start?
​
  The draft also mentions methods that Endpoints can use to find Posture servers.  I wonder if Zeroconf or some kind of DHCP trick might work for this?

​Zeroconf is an option. TCG has some prior art here (https://www.trustedcomputinggroup.org/wp-content/uploads/Server_Discovery_And_Validation_v1_0r19-PUBLIC-REVIEW.pdf). I am happy to consider all viable options.​

  Finally, in Security Considerations, I wonder if there should be something about how much we do or don’t trust the endpoint to report its Information truthfully. The combination of 802.1AR and signed SWID tags might help with a way to assess the reliability of the information.

  Great start, let’s try to start breaking down some of the top-level topics to get to the next level of requirements.
Thx,
/guy

_______________________________________________
Panic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/panic

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 27 Jul 2017 16:49:21 +0000

Adam et al.,
Yes, there are a lot of places where sacm, panic and mile overlap. If you
haven't read it, check out this (shamelessly self-promoted) article:
https://www.ietfjournal.org/working-group-update-security-automation-and-continuous-monitoring/
It describes my point of view of how these efforts intersect. I'd love
feedback on it.

Thanks,
Jess

On Wed, Jul 26, 2017, 4:55 PM Adam Montville <[email-masked]>
wrote:

> Our SACM-related hackathon efforts are mostly documented at [4]. (Note
> that there were two SACM-related efforts, though only one was exclusive to
> On Wed, Jul 26, 2017 at 1:46 PM Jessica Fitzgerald-McKay <
> [email-masked]> wrote:
>
>> Also, secure though 802.1ar is, it often has no relation to any
>> observable device identities on the network. I'm thinking about a behavior
>> monitoring use case here, in which I notice a device behaving in an
>> unexpected manner, and want to investigate it's posture while I figure out
>> what is going on. Is there a way to gather many identities from an network
>> device using netconf/yang?
>>
>>
>>>

---

From: Adam Montville <[email-masked]>
Date: Fri, 28 Jul 2017 11:33:47 +0000

Thanks for sharing that link, Jess. I had seen the article when the Journal
was published. When considering that there are further downstream uses of
collected information, I'm wondering what the value is of, in effect,
having two points of evaluation: Compliance Server and Evaluators.

Before getting into this, I do want to point out that I believe we are on
the same wavelength with respect to the outcome: We want a cooperative
"ecosystem" of capabilities (very likely implemented by multiple vendors)
to increase the efficacy of enterprise security programs. I say that at the
risk of overstating your views, but I think that's about right.

Consequent to our hackathon efforts, I'd call your attention to [1]
generally (our current write-up on approach and outcomes) and [2] (the last
diagram on that first page at [1]). Because the data collected is
ultimately destined to support a widely-scoped security program, it may
make more sense to go for the wider data sharing problem more immediately
in the solution's architecture. In a sense, the Compliance Server described
in your article is one that serves, in reality, multiple purposes: One
component (StrongSwan in the hackathon effort) is part of a SACM Collector,
and the other component is an evaluator and datastore. It may make sense to
decouple those multiple purposes, so that the Compliance Server portion of
the ECP solution becomes a consumer of collected information, just like any
other evaluator.

There may be no reason (other than limited bandwidth in this wider
community) one approach should be excluded in favor of another.

All that said, I, too, am very interested in gaining additional feedback
from others on this list, the SACM list, and/or the MILE list.

Kind regards,

Adam

[1]

[2]

On Thu, Jul 27, 2017 at 11:49 AM Jessica Fitzgerald-McKay <
[email-masked]> wrote:

>>>>   It seems that the next step in moving this forward might be to
>>>> outline the kind of information we want to retrieve from the endpoints.
>>>> I’d assume you’d want some kind of info to identify the device –
>>>> manufacturer, serial number, etc, plus something that shows the software
>>>> revision of the relevant modules.  Could that be something like a set of
>>>> SWID tags?
>>>>
>>>
>>> ​Personally, I would be delighted if software load could be captured in
>>> a SWID tag. Failing that, I would like to be able to collect a swid-like
>>> set of information from​ the network device. I took a look at NISTIR 8060
>>> All things considered, I'd like to use SWID tags. I would like a sense
>>> of how widely implemented they are for network device software and
>>> operating systems. Anyone have any insight there?
>>>
>>>
>>> ​Agreed that IoT is a problem. Do many "Things" that compose the
>>> Internet of Things implement netconf?​ It's such a broad space, I worry
>>> that some "Things" could handle netconf, and others (things like "smart
>>> dust", etc.) couldn't handle the added weight.
>>>
>>>
>>>>
>>>>   The draft also mentions methods that Endpoints can use to find
>>>> Posture servers.  I wonder if Zeroconf or some kind of DHCP trick might
>>>> work for this?
>>>>
>>>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:39:57 +0000

Hi Jess,

To try to address two questions:

> I would like a sense of how widely implemented they are for network device software and operating systems. Anyone have any insight there?

I am not aware of any network vendors that use SWID tags.

> 802.1ar requires installation ​
​of an IDevID, from which many LDevIDs can be created. I'm happy to geek out on the added security of cryptographic IDs, but, can we talk though the workflow of getting the initial IDevID installed (who would be responsible for that? Do network equipment vendors use IDevIDs today?

I can’t speak for all vendors, but Cisco has been using IDevIDs in their products for some time and more platforms are adopting it. The private key for the 802.1AR cert is stored in a secure storage chip (similar TPM) so the IDevID cannot be compromised. I applaud adopting a secure immutable identity or better a subsequently acquired LDevID to authenticate the reported data from the endpoint. Fallback or additional auth mechanisms will also be necessary for other usecases though.

Rgs,
Panos

From: Panic [mailto:[email-masked]] On Behalf Of Jessica Fitzgerald-McKay
Sent: Wednesday, July 26, 2017 2:46 PM
To: Guy Fedorkow <[email-masked]>
Cc: [email-masked]
Subject: Re: [Panic] notes on Panic Draft

Hi Dave, Jessica,

  *   software name and
  *   software version,

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Sat, 29 Jul 2017 02:40:43 +0000

Hi Jess,
FYI, for Huawei network products, the answers are the same.

B.R.
Frank

发件人: Panic [mailto:[email-masked]] 代表 Panos Kampanakis (pkampana)
发送时间: 2017年7月28日 23:40
收件人: Jessica Fitzgerald-McKay; Guy Fedorkow
抄送: [email-masked]
主题: Re: [Panic] notes on Panic Draft

Hi Jess,

Rgs,
Panos

From: Panic [mailto:[email-masked]] On Behalf Of Jessica Fitzgerald-McKay
Sent: Wednesday, July 26, 2017 2:46 PM
To: Guy Fedorkow <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Panic] notes on Panic Draft

Hi Dave, Jessica,

  *   software name and
  *   software version,

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 30 Jul 2017 20:21:02 +0000

Hi,

There is some work on hardware fingerprinting (derived from circuit noise) that could be applicable here. It would require an initial trustworthy access to the device, or a trusted database of fingerprints, but could address almost all cases, in special when dealing with constrained devices.

We have been working with a research group looking at these issues (their head is in Cc:) and here you go a few references of what they are doing:

  1.  Device authentication by inclusion of dedicated hardware:

Hardware dedicated modules have been designed to authenticate the ASICs and FPGAs where they are included. They are based on Physical Unclonable Functions (PUFs), which are functions whose outputs to given inputs can only be generated by the genuine device. The modules implement security primitives particularly related to key generation, identifiers, and random numbers. Security against hardware attacks has been especially analyzed, particularly side-channel attacks such as differential power analysis (DPA).

Some related papers:

  *   “Hardware authentication based on PUFs and SHA-3 2nd round candidates”, by S. Eiroa, I. Baturone. Proc. ICM 2010, 22 Int. Conf. on Microelectronics, pp. 319-322, Cairo (Egypt), 20-22 December 2010. DOI: 10.1109/ICM.2010.5696149

  *   “Circuit Authentication based on Ring-Oscillator PUFs”, by S. Eiroa, I. Baturone. Proc. 2011 18th Int. Conf. on Electronics, Circuits and Systems (ICECS’2011), pp. 691-694. Beirut (Lebanon), 11-14 Dec. 2011. DOI: 10.1109/ICECS.2011.6122368

  *   “FPGA implementation and DPA resistance analysis of a lightweight HMAC construction based on PHOTON hash family” by S. Eiroa, I. Baturone. Proc. 2013 23rd Int. Conf. on Field Programmable Logic and Applications (FPL’2013), Oporto (Portugal), 2-4 Sept. 2013. DOI: 10.1109/FPL.2013.6645605

  *   “A VLSI Module To Authenticate Unclonable Things”, by I. Baturone M. A. Prada- Delgado, S. Eiroa. Proc. 19th IEEE Int. Symp. on Consumer Electronics, ISCE 2015, pp. 1- 2. Madrid (Spain) 24-26 Junio. 2015. DOI: 10.1109/ISCE.2015.7177831

Chain-of-trust for interconnected devices via firmware reprogramming:

A highly secure software platform is being developed that, once injected in the devices via firmware reprogramming, will provide cryptographic and physical authentication techniques, avoiding counterfeit of the devices in a network. No dedicated hardware is needed.

Some related papers:

     *   “An unclonable token for a secure document management system”, by I. Baturone, M.A. Prada-Delgado, S. Eiroa, J.A. Prieto, Demo Session (Invited). Intel Workshop on Cyberphysical and Mobile Security: Intelligent Things, Vehicles and Factories, 2014. Darmstadt (Germany) 10-11 June. 2014

     *   “Robust Unclonable Identifiers and True Random Numbers from off-the-Shelf SRAMs” by M.A. Prada-Delgado, S. Eiroa, I. Baturone. Demo Session. Proc. DASIP 2014, Conf. on Design & Architectures for Signal & Image Processing, 2014. Pages: 1 – 2. Madrid (Spain) 8-10 Oct. 2014. DOI: 10.1109/DASIP.2014.7115613.

     *   “Improved generation of identifiers, secret keys, and random numbers from SRAMs”, by I. Baturone, M.A. Prada-Delgado, S. Eiroa, IEEE Transactions on Information Forensics and Security, Vol. 10 (issue 12) pp. 2653 - 2668. Dec. 2015. ISSN: 1556-6013. DOI: 10.1109/TIFS.2015.2471279

     *   “SRAM-based Physical Unclonable Keys for BLE Smart Lock Systems”, by M.A. Prada- Delgado, A. Vázquez-Reyes, I. Baturone, L. Acasandrei, D. Fernández-Barrera, J. Prada- Delgado. University Booth Demo in DATE 2016, Design, Automation and Test in Europe, 14-18 March, 2016, Dresden (Germany).

Be goode,

On 28 Jul 2017, at 17:39 , Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jess,

Rgs,
Panos

Hi Dave, Jessica,

  *   software name and
  *   software version,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição