Smart Meter Security Analysis
From its-wiki.no
| Wiki for ITS | ||||||
|---|---|---|---|---|---|---|
|
|
Smart Meter Security Analysis
| by | N.n. |
|---|---|
| Supervisor(s) | György Kálmán, Josef Noll |
| Due date | 2017/12/01 |
| Status | Planned |
| Problem description: | Within 1Jan2019 all electricity customers in Norway will have to use smart metters. These smart meters (SM) will become part of the ”Avanserte Måle- og Styringssystemer” (Automatic Meter Systems - AMS), and include that users can have a better information on their electricity usage, a more accurate billing of their consumption and the opportunity for automatic controlling of the power consumption. Pilots have already been running at several places in Norway. Academia, Grid distributors, Industry, and Consumer Organisations have joined through the IoTSec.no initiative to discuss security and privacy related to the services and infrastructures in an AMS.
This thesis will focus on security and privacy of the meters themselves. The thesis will compare smart meters with other infrastructures like payment terminals, and provide a classification of security of the components of the smart meter. |
| Methods and Tools: | The tools and methods in this thesis are based on
|
| Time schedule | The envisaged time schedule (for a long thesis/60 ECTS) is:
|
| Pre-Knowledge | This thesis includes a reasonable amount of practical testing in addition to the security analysis. The students are encouraged to have a security background. |
| Approved | Pending by |
| Keywords | IoTSec, Smart metering, AMS |
| Depiction |
this page was created by Special:FormEdit/Thesis, and can be edited by Special:FormEdit/Thesis/Smart Meter Security Analysis
Please see Oppsett_av_Masteroppgaven_om_smarte_meter.
Contents
Draft TOC - to be adapted
This section provides hints on what to include in your master thesis.
Title page, abstract, ...
- 1. Introduction, containing: short intro into the area, what is happening
- 1.1 Motivation, containing: what triggered me to write about what I'm writing about
- 1.2 Methods, containing: which methods are you using, how do you apply them
- 2. Scenario, optional chapter for explaining some use cases
- 2.1 user scenario, (bad name, needs something bedre)
- 2.2 Requirements/Technological challenges
- 3. State-of-the art/Analysis of technology, structure your content after hardware/SW (or other domains). Describe which technologies might be used to answer the challenges, and how they can answer the challenges
- 3.1 technology A
- 3.2 technology B
- 4. Implementation
- 4.1 Architecture, functionality
- 4.2
- 5. Evaluation
- 6. Conclusions
- References
Comments
Red line
Your thesis should have a "red line", which is visible throughout the whole thesis. This means you should mention in the beginning of each chapter how the chapter contributes to the "goals of the thesis".
Use of scientific methods
A thesis follows a standard method:
- describe the problem (problemstilling)
- extract the challenges. These challenges should be measurable, e.g. method is too slow to be useful to voice handover.
- Analyse technology with respect to challenges. Don't write & repeat "everything" from a certain technology, concentrate on those parts (e.g. protocols) which are of importance for your problem
References
- Wikipedia is good to use to get an overview on what is happening. But there is not scientific verification of Wikipedia, thus you should use wikipedia only in the introduction of a chapter (if you use text from wikipedia). Use scientific literature for your thesis.
- Scientific library is "at your hand", you can get there directly from UiO: [[How to get access to IEEE, Springer and other scientific literature -> Unik/UiOLibrary]]
- I suggest that references to web pages, e.g. OASIS, W3C standards, are given in a footnote. Only if you find white papers or other .pdf documents on a web page then you refer to them in the reference section.
Evaluation of own work
Perform an evaluation of your own work. Revisit the challenges and discuss in how you fulfilled them. Provide alternative solution and discuss what should be done (or what could have been done).
