From cc2e0a67af497685cbcb3d92700f85359f8eab87 Mon Sep 17 00:00:00 2001 From: lukasmittag Date: Fri, 8 Mar 2024 11:05:50 +0100 Subject: [PATCH] Adapt documentation --- kuksa_databroker/doc/behavior.md | 4 ++++ kuksa_databroker/doc/timestamp.md | 5 ----- 2 files changed, 4 insertions(+), 5 deletions(-) create mode 100644 kuksa_databroker/doc/behavior.md delete mode 100644 kuksa_databroker/doc/timestamp.md diff --git a/kuksa_databroker/doc/behavior.md b/kuksa_databroker/doc/behavior.md new file mode 100644 index 00000000..bee5441f --- /dev/null +++ b/kuksa_databroker/doc/behavior.md @@ -0,0 +1,4 @@ +# Runtime behavior and potential attacks +The implementation of KUKSA databroker shall represent the latest value of a ```Datapoint```. Therefore the databroker always sets a ```timestamp``` for a ```Datapoint```. This means if a new value comes in it overwrites the older value. We opted for this behavior because a actuator/provider/application can have no access to a system time. For some use cases it could be interesting to provide a timestamp set by the actuator/provider/application. For this we added a so called source timestamp (short ```source_ts```) to the ```Datapoint``` class. This source timestamp is optional and per default set to None. + +If an attacker gets an authorized connection to the databroker he can set the source_timestamp and overwrite the value with a new one. But for this he/she needs read and write access through JWT tokens. If a provider decides to work with ```source_ts``` of a ```Datapoint``` than it should be clear that they can be false/outdated. diff --git a/kuksa_databroker/doc/timestamp.md b/kuksa_databroker/doc/timestamp.md deleted file mode 100644 index a8eed404..00000000 --- a/kuksa_databroker/doc/timestamp.md +++ /dev/null @@ -1,5 +0,0 @@ -# Databroker Timestamps -The implementation of KUKSA databroker shall represent the latest value of a ```Datapoint```. Therefore it adds a ```timestamp``` to a ```Datapoint```. If an actuator/provider/application has no system time the databroker sets the ```timestamp``` to the current system time. For some use cases it can be interesting to provide a timestamp set by the actuator/provider/application. For this we added a so called source timestamp (short ```source_ts```) to a ```Datapoint```. This source timestamp is optional and per default set to None. - -# Potential attacks -If an attacker gets an authorized connection to the databroker he can set the source_timestamp and overwrite the value with a new one. But for this he/she needs read and write access through JWT tokens. If a provider decides to work with ```source_ts``` of a ```Datapoint``` than it should be clear that they can be false/outdated.