Software Requirements Document - Linux_LL... · The kiosk will be the entry point to scan products,...

EVENTOS Linux LL Functional Requirement for Kioskware Module

eVentos - Linux_LL System Requirements Document draft v0.4 Last Updated 2/20/2018

Tuesday, February 20, 2018 EVENTOS 2018 | Confidential Page 1 of 39

Software Requirements Document LINUX for Kioskware

Author:

Juergen G Weber

(For Vitality Handels- und Dienstleistungs GmbH)




SRS Revision History

Date Version Description Author

17. February 2018 0.1/0.2 Initial Draft Juergen Weber

18. February 2018 0.3 Added Info originally from King Frog (must

be reviewed)

Juergen Weber

19.February 2018 0.4 Adding Mender .io info Juergen Weber




Inhalt

Introduction........................................................................................................................................................................4

Overview Chart...................................................................................................................................................................... 5

Glossary ................................................................................................................................................................................. 6

Functions Prequel.................................................................................................................................................................. 7

User Interface at self-check-out kiosk ................................................................................................................................... 8

UX – Screen ........................................................................................................................................................................... 9

5. Functional Requirements Section 5.x with Kiosk Frontend ....................................................................................... 10

6.1 Linux Bootloader, OS, Driver, Libraries, Remote Setting, Communication w. Biz Logic ................................................ 14

6.2 Remote Setting with Dashboard/Graphical Admin Panel ............................................................................................. 15

6.3 Linux Overview .............................................................................................................................................................. 16

6.4 Linux Bootloader ........................................................................................................................................................... 17

6.5 Remote Setting with Dashboard/Graphical Admin Panel ............................................................................................. 21

7.0 Secure Communication ............................................................................................................................................... 23

Cryptographic protocols ...................................................................................................................................................... 23

7.1 Local Database ............................................................................................................................................................ 27

Cryptographic protocols ...................................................................................................................................................... 27

7.2 PKI (by King Frog) to be reviewed ............................................................................................................................... 28

Certificates .......................................................................................................................................................................... 28

Development Requirements by Vitality GmbH ................................................................................................................. 32

Redmine, Github, Test Environment ................................................................................................................................... 32

API Specification – Draft (based upon S……X) ..................................................................................................................... 37

Introduction – This is a sample- Definition must be made! ................................................................................................ 37

API Keys ............................................................................................................................................................................... 37

Configuration API ................................................................................................................................................................ 37

Examining the API ............................................................................................................................................................... 38

API Call Structure ................................................................................................................................................................ 38

Difference in Business Logics .............................................................................................................................................. 38




Introduction

Product Description: EVENTOS is an independent POS and ERP service platform to be used as major parts of our eco

system in self service retail. Front ends may be kiosk system, fridges with locker and sensor array, intelligent shelves

with active price tabs and locations with object detection by software means.

Information are available in our dropbox repository, as well as in redmine [LINK: https://www.eventos-dev.com ] .

We have user stories and BPMLs for different use cases and scenarios available. THIS SRD is only for the Operating

system port and adaption, including the drivers of the build-in modules. It describes the required FUNCTIONS only, not

the execution in software logic or tools to be used.

First phase will be a single test micro market, operates with our floor standing 32” portrait mode kiosk model. It is

planned, to use a MVP milestone software to test the software, and improve it then during the fully operating test

market. A roll-out hereafter is scheduled in a franchise-model. All markets are un-manned during operation times.

Only ONE operator (franchise –partner) shall fill sold goods back into shelves, check the kiosk or the other sensors for

running.

Image 01: EVENTOS kiosk for first Vitality Micro Market in Germany




Overview Chart

The EVENTOS ecosystem for self-service retail in it´s version with self-check-out kiosk as the front-end will consist of :

1. Kioskware (Frontend) [Bootloader, Linux Kernel, Driver, Communication Layer, JVM, Javapos, React.js (Bizlogic

either in Java or in Node.js]

2. Middleware (EBS)

3. Backend (This document is for the backend with ODOO 11 community version)

Image 02: Overview-Software_2018-01-26c




Glossary

SLEEP MODE: Kiosk CPU and Main Board are in sleep mode

STAND BY MODE: Screen shows Advertisement, Still-Picture, Carousel, Video as Option, Barcode Scanner,

Fingerprint Sensor, NFC reader, Bluetooth LE is working.

OFF-LINE MODE: Transaction is possible, payment method is limited to payment with Vitality NFC Card or

Smartphone Apps on Android and iOS phones. Credit- and Debit Card based payments do

require live internet connection!

REGISTERED USER: A registered user can enjoy, pre-settings, means he has not to enter for example EAT-IN vs.

EAT OUT, payment method is pre-selected by system, can use Vitality Card or APP

GUEST: Guests can purchase without registration process, use either Girocard or Credit Card. APP or

VitalityCard not available for Guests.

KIOSK: Kiosk with a touchscreen, barcode scanner, payment terminal, NFC and Bluetooth reader,

receipt printer. CASHLESS payment methods only. Bank Note acceptor is located in a

separate side-kick device (optional with NFC guest card dispenser)

-.




Functions Prequel

The kiosk will be the entry point to scan products, taken out of open retail shelves, scan hot drink

barcode on either cup or receipt, sell vouchers for hot drink machine (either-or).

It will be used to pre-order food for next days +14 days delivered to place.[Project-Code: Gelsenkirchen

]

It may be used to check “My account”, do enrollment and registration, if not done by Mobile Phone

App. Later is to be preferred to avoid lines during rush hour, i.e. lunch break!

To improve User Experience, we will have to run transactions locally on kiosk, which will be synced

hereafter. Only missed data shall be from case to case fetched from back end during transaction. Kiosk

will perform transaction (limited in functionality) also when off-line. SYNC of local db and back-end is

crucial here.

Besides the kiosk as an entry point we will have other self-service devices in the very near future.

Means the back end and middle ware must communicate with different front-end-types (IOT) not only

kiosks.

Image 03: Overview software vs. different hardware at front-end

System shall be installed to provide our Franchise partners the service as SAAS. Means a Franchisee

may operate one or more markets. Purchase of goods by our registered suppliers will be via a central

purchase method, which also will control in phase 2 then the to be implemented SUPPLY CHAIN

MANAGEMENT-




User Interface at self-check-out kiosk

We plan to have a rich graphic fast responsive UI/UX. This will be programmed in “react.js”. The

screens we plan to use will be 32” portrait and 15.1” landscape. So interface will be fully responsive.

Good to look at this video in youtube: [LINK: https://www.youtube.com/watch?v=05u9c9u1S0s ]

Search: McDonalds Kiosk will give many other videos showing the UI/UX . A design example (prototype

only) is here:

Image 04: UI prototype made wish Photoshop

Set of Wireframes are available in Dropbox.




UX – Screen

Flow and Entry Points, depending on Barcode, Fingerprint, NFC (Bluetooth)

Image 05: Start-System Wake-up and Entry Screens




5. Functional Requirements Section 5.x with Kiosk Frontend

(Section 5 of EVENTOS eco-system with Self-Service-Kiosk)

The functional requirements describe the core functionality of the application. This section includes the data and

functional process requirements. REMARK. Functions described in setup with a EVENTOS Self-Service Kiosk. Besides Kiosk

Front-End, our Middle-Ware and the Backend must serve also SELFI and INTELLI-FRIDGE.

5.1 User Inter-Action at Kiosk: Scan a good/ or goods for purchase Input: User may scan his goods, or a single product; identifies himself with ID card (NFC)

or by smartphone (NFC/Bluetooth LE/Wi-Fi) /or proceed as a guest (unregistered)

Output: trigger payment terminal, print receipt or send receipt by email or load into

App database | Update ERP database about products sold and store the transaction

data

Prototyp

MVP

5.1.1 A customer shall be able to scan his goods he wants to purchase at the Datalogic

Magellan 3200vsi scanner, which is a build in module in the self-check-out kiosk

Must

5.1.2 The customer shall be able to scan the barcode or manually enter a code number

instead – optional he shall enter the shown weight & code number which is printed on

the label of a fresh packaged good.

Must

5.1.3 He must be able to read nutrition information and description of the good, presentation

in pop up window on screen.

Must

5.1.4 He must be able to scan up to 20 different products (#.t.b.d) Limitation by the software

is not needed.

Must

5.1.5 He must be able to choose his language, English, French, German, eventually later other

languages. Language package must be easy to add on by the admin. Also all other

ocuntry specific settings.

Must

5.1.5.1 The user must choose EAT-IN or EAT-OUT . The background for this choice is, that we do

have in Germany two different VAT sales tax rates for food and drinks (non-alcoholic) to

be consumated in the premise 19%, versus when takenout it is the lower rate of 7%

Depending on the customers entry-point he will have to opt as one of the first screens

(03 EAT-IN/EAT-OUT wireframe) or if entered direct to scan page (07 wireframe) then

he can change the default version when reviewing the cart, while checking out. (08 cart

review). Database fields required accordingly.

Must

5.1.6 The customer shall be able to click on Help button to get connected to Help Service

(t.b.d) Help button shall be on same position on all screens.

In a phase to be defined, customer will have the chance for vidoe/or audio

communication with a help agent

Must

5.1.7 Once the Language of choice has been selected, all operations and results on the

website shall be for the same language. Back end must also be Multi-language

MVP

5.1.8 When the customer searches for the various information after choosing the appropriate

fields, the UI shall fetch the details from eVentos backend.Transactions for speed

reasons shall take the data out of the local database, only when not stored locally,

application shall fetch data from ERP back end.

SEARCH: Most probably only applies when a lunch meal is searched.

PUSH info of changed info to all or selected kiosk or other front-end devices.

Only entry point to make price changes is done in the ERP module!

Must




5.1.9 The user must see the tax and the bottle deposit within the billing info before he will

have to pay.

When his employer subsitutes his purchase, this amount must also shown.

Must

5.1.10 By clicking on checkout and pay button, he will be presented all available payment

options. Those depends on location/kiosk or user (registered or guest)

Must

5.1.11 When cash-less option is taken, in case of all Credit- and Debit-Cards, no matter which

standard the execution will be done via the payment terminal, which is to be handled

accordingly to EMV requirements and in Germany also accordingly to the banking

association, ZVT protocolls and requirement

Must

5.1.12 We may handle directly without the payment processor (external supplier) the billing

process for the employees, to be deducted from the payroll, also we may execute our

own Wallet Prepaid/loyality card [Vitalitycard/-app] solution internally, but may follow

strict PCI requiremens.

NEW PRIVACY DATA LAWS APPLY IN EUROPE!

Phase II

5.1.13 The result rendered on the kiosk display or App shall be sortable by class, price or name

(class= beverage cold/hot, Snacks, Food, Special Food. Not applicable for scan product

string. Sort only needed when Food pre-oder is active.

Must

5.1.14 The customer shall be able to choose to get a receipt: a) as print out at kiosk; b) sent to

e-mail address; b) sent to his App; t.b.d integration of we-chat or what´s up

Must

5.1.15 A customer will have in some kiosk location the option to pay in cash. However the

intention is, that a transaciton can not be paid in cash, as we have no technical feature

to return the change!

USE CASE THEREFOR:

Banknote Acceptor will be in a separate unite called “The Side-kick”. Our standard kiosk

will have no banknote accpetors build in. User may load on the Side-kick his Vitality NFC

Card or Vitality APP as such.

Optional the “Side-kick” will have a dispensor for Vitality-un-registered guest cards. He

may obtian in one-transaction of XX EUR a card, which is charged with the amount he

has choosen. Return of such card must be analyzed how to realize a possible return.

Using acceptance hardware for return process is costly! (May be return by mail!?!)

Must

5.1.16 All information shall be stored locally and on the Server based Business Logic. All local

data will be erased after xx hours (t.b.d). local storage shall be encrypted and only used

for speed transaction (See for reference Catapult ECRS) Sync Process to be discussed!

Must

5.1.17 Options on the kiosk are My Account . Enrollment possible on Kiosk or on dedicated

responsive Web Formular. Enrollment not possible on Rush Hours!

Enrollment of the fingerprint sensor must be on the kiosk itself- as the smartphones

sensor cant be used.

Enrollment process may take time? Preferrably not during lunch break…..

May be we need to use a Notebook of Operator to do a face-by –face entrollment.

Further investigation is reguired.

Must

Fingerprint

Use is not

Within MVP

5.1.18 Further option to pre-order special meals…… contray quick transactions within rush

hours

Phase 2




5.1.19 In case the customer abandons a transaction half-way through the process, the lock on

the record shall be released after 5 minutes.

Must

5.1.20 While doing the check-out, a picture will be made of consumer and stored in encrypted

way.

ATTENTION: We must be comply with new Privacy Rules in EU.

Storage of such in the ERP or in the Video Suveilance Files??

Must

5.1.21 Cancellation process to be defined when good(s) shall be given back.

Entire Business Case must be role defined

IN Software and Physically

Must

5.1.22 Type of goods as above: Beverages, hot and cold, Snacks packaged, Food standard

offerings, Food fresh daily, Special pre-order Food, others…

SEE user-story: Colombia for Hot Drinks

5.1.23 After the personal details are collected from the customer by the use of his workplace

ID card or the Vitality Wallet ID card, the browser shall be redirected to the payment

screen.

METHOD ONLINE:

User can pre-register online on a website/app. First use he can enter a PIN at the kiosk

for verification. APP can be used directly. Physical card must be send to him by mail

(picked up at agreed time from local operator (franchise partner)

Must

5.1.24 Registered users or guests can start scanning without identification!

This is a gread advantage of the kiosk version in opposite toall other autmated ways of

retail shopping!

Must

5.1.25 For mobile app based reservations, All payments shall be done through HTML/web

based screens and not through in-line payment. This will ensure that EVENTOS doesn’t

pay heavy commission to Apple or Google.

Verification required with payment provider when we accept Credit Card or Debit Card

Payment, otherwise than loading the Vitaltiy Account.

PSD2

Inquiry made with BaFIN to learn regulation of new PSD2!

Must

5.1.26 The change from mobile app to the web based payment screen shall be seamless.

Must

5.1.27 On successful completion of payment, all transaction data with time stamp codes shall

be stored and made accessible for further use within ODOO ERP software, preferable

stored in one common db.

Must

5.1.28 The session can be started in a multi-way approach. See Image: Image 05: Start-System

Wake-up and Entry Screens

By Finger, when touching the display in stand-by mode.

By Barcode on a product, when moved in front of the scanner

By NFC card/Android App when registered user

By Bluetooth LE and iPHone when registered user

Must




By barcode, when the employees ID card has a barcode printed on card

Any of those methods may bring the customer to either a dedicated side or the SCAN

GOODS page directly.

5.1.29 In Germany employees may get a tax free grant as substitute by their employer. This

must be settable at the proper check-out step. Tax rules apply and must be managed in

the general settings.

Must

5.1.30 Database and Setting fields for the different options in tax saving plans for employee´s

Phase 2

5.1.31 Must

5.1.32 Must

5.1.33 Must

5.1.34 Must




6.1 Linux Bootloader, OS, Driver, Libraries, Remote Setting, Communication w. Biz Logic

6.1 Operating System Linux Ubuntu 16.04 desktop Input: All modules connected via USB

Output: On screen; Command line, or in Libreoffice

6.1.1 First test made with this set-up:

Mainboard HW-001 Fodenn IPC-I1151 P01

CPU HW-002, Intel G4560 dual core, 3,5 GHz

RAM DDR4, RAM 2.133 MHz, HW-003

USB stick to boot

USB stick as install target

PSU HW-005

Touch Screen Module HW-006 connected via DVI-D to HDMI (cable), USB 2.0 touch

HW-009 NFC reader (not tested)

HW-010 Board not tested as in development

HW-011 Printer is recognized, but not tested

HW-012 Magellan Barcode Scanner, USB connected regoniced as Keyboard Entry

(has barcode recognized and writes it into command line or in Ubuntu in open

Libreoffice page with carriage return)

HW-013 connected via USB no test

HW-014 not available

HW-015 ATM camera connected via USB no test

TEST SETUP:

Ubuntu 16.04.3 LTS

Hardware as above, Ubuntu 16.04 desktop version with Win32diskimager copied to USB

stick, then booted and installed the distribution onto a second USB stick.

The test setup has no Harddisk (Dead-on-arrival)

System rebooted, Touch worked, Screen size worked 4.3 on 15.1inch Module HW-006

Ubuntu desktop worked, installed Teamviewer version 12,

When Movement in front of scanner, the light turns on, (Sensor working), when having

barcode on cans, it worked, it wrote either into comman line, or when I have opened

Libreoffice, it wrote the barcode as numbers into the Libreoffice page.

Printer was visible as Custom printer. No further testing done.

Before this Ubuntu test, we also had Rancher OS as such running.

Hands-on

test

6.1.2 Decision, which distribution is best for us. In regard of:

Speed and lowest possible cost to port the bootloader and OS

Availability of the drivers

Remote setting on dashboard

Libraries

Prototype I

6.1.3 This drivers must work in Prototype

Ethernet (OK)

Prototype I

6.1.3 Monitor (OK) Prototype I

6.1.4.1 Touch (OK) Prototype I

6.1.4.2 Touch 32” Portrait Mode MVP Must

6.1.5 Barcode Scanner Keyboard Entry Device (OK) Prototype I

6.1.6 NFC Reader Prototype I

6.1.7 Custom K80 Barcode reader Prototype I

6.1.8 ATM Camera Prototype I

6.1.9 Bluetooth Reader MVP Must




6.1.10 Microphone Array >Firmware on board EVP-21 MVP Must

6.1.11 ZKTeco Fingerprint Sensor MVP Option

6.1.12 USV integration MVP Must

6.1.13.

1

Payment Terminal Yomova MVP Must

6.1.13.

2

Payment Terminal CCV 820 MVP Must

6.1.14 Secure Smart Card USB connection (Firmware on smartcard controller board) MVP Option

6-1-15 Secure Smart Card Controller Board Firmware and HW Test. MVP Option

To be defined communication with the middle- high – level software in react.js /java

/t.b.d.

6.2 Remote Setting with Dashboard/Graphical Admin Panel

6.2 Operating System Linux Remote Setting

Input:

Output: Graphical Dashboard

See also 6.5

6.2.1 As our Kiosk System in un-manned – we must have an external graphical dashboard for

ALL admin and device setting issues.

ALL settings, like for example ATM-Cam resolution must be done via this remotely

connected dashboard/admin-panel.

Following segments list the setting modules

6.2.2 Printer

6.2.3 ATM-Camera

6.2.3 Barcode scanner – eventually we need to to this via the Javapos drivers and utility

software provided by Datalogic

6.2.4. NFC-reader

6.2.5. Secure Smart Card

6.2.6 Audio 4 x Mems Microphone board

6.2.7 Fingerprint Sensor

6.2.8 USV

6.2.9 Touch

6.2.10 Empty

6.2.11 Empty

6.2.12 Empty




6.3 Linux Overview

Image: Linux Kernel Structure © Von Tux.svg: Larry Ewing, Simon Budig, Anja GerwinskiThomei08 -

Tux.svgown work (selbst erstellt), Gemeinfrei,

https://commons.wikimedia.org/w/index.php?curid=7905750

6.3 Operating System Linux Kernel

Input:

Output:

6.3.1

Layers Hardware > Kernel Mode > User Mode

6.3.2 Licence rules must be clarified. (BLOP free?)

6.3.3

6.3.3

6.3.4.




6.3.5.

6.2.6

6.2.7

6.2.8

6.2.9

6.2.10

6.2.11

6.2.12

6.4 Linux Bootloader

6.4 Bootloader (This segment written by King Frog must be overworked)

Input:

Output:

6.4.1 Secure Bootloader

The kiosk uses a bootloader that launches the main GUI and other services.

That bootloader will check file integrity from a database of hashes , then will access the

decryption keys - then will decipher the main GUI and the components and finally load

them in memory.

The fact that the GUI and the main software components are ciphered ensures that a

compromised kiosk could not be revers engineered easily in order to create 'cloned'

kiosks.

The bootloader behave as such when it starts running at kiosk startup:

1. block OS access immediately with a 'splash screen'

2. get access to the local database

3. get access to the deciphering keys

4. check for updates

5. if an update is available, download it and replace the ciphered folder by the

new folder

6. if an update is available update the table of hashes

7. decipher the ciphered folder into a temporary folder ( ideally a RAM folder )

8. check file integrity against the table of hashes

9. if a file integrity has been potentially detected block the POS and display an

error message

10. launch all auxiliary processes : diagnostic, process checker, etc...

11. launch the main program ( GUI )

12. stay in background

Note that the secure bootloader must NOT have the deciphering keys hardcoded , the

keys must come from a secure storage.

6.4.2 Default Factory OS

We should work with multi-partitions, so when an update fails, the original code is still




there in an other partition.

6.4.3 Diagnostic

That thread from the bootloader samples the RAM, disk and battery status periodically.

The connection to internet and other data ( IP,...) are also sampled.

Data are stored to the local database and sent periodically to the sever as batches.

The kiosk pings periodically the server to signal that it is connected

6.4.3 File checker

That threads from the bootloader check file integrity using a database of hashes

6.4.4. Process Checker

That thread from the bootloader check that only authorized processes are launched and

check periodically that the GUI is running and relaunch it otherwise

6.4.5. Update Mechanism

The update mechanism and the initial personalization mechanisms shall be performed

by the Eventos server.

6.4.6 Firewall

The kiosk have a built-in firewall that prevents unauthorized inbound and outbound

connections.

6.4.7 Events Logger

All events are logged in a table of the local database and sent by batches to the kiosk

server.

Events are classified by four levels :

– info

This is information data

– warning

this correspond to a problem/anomaly that has no direct impact in the functions of the

kiosk

– error

this corresponds to a serious problem which will not crash the whole application

– critical

this corresponds to a crash of the application

6.4.8 Platform Independent Middleware

The kiosk application shall provide as much as possible a platform independent

software, eg that can be used on different similar hardware.

The kiosk application shall use an abstract hardware layer that contains the immutable

functions for:… hardware listed in the devices section.

For example, the kiosk should use such functions absolutely independent of the printer:




string print_ticket(string msg, int size_char, enum_font font, …)

that function should use the various low-level function provided by the drivers to

perform the task

Illustration : Hardware independent kiosk

6.4.9

6.4.10

6.4.11

6.4.12

6.6 Linux Updater

6.6 Updater Mender.io

Input:

Output: Mender is an end-to-end open source updater for connected devices and IoT. Question

it works out of box with

6.6.1 Mender is an open source remote software updater for embedded Linux devices. It

includes both a client and a management server, which are both licensed under Apache

2.0.

Mender enables the management of software updates to connected devices remotely

over any TCP/IP network. Mender can update devices over-the-air (OTA), but also

enables standalone deployments which can be used to deploy updates through external

storage such as a USB stick.

Mender allows you to deploy an image-based update from the server-side component

to your connected device or fleet of devices. The deployment is done securely using

HTTPS and the partitioned setup makes sure your device will stay up and running

should anything interrupt the update process. Mender also supports code signing for

added confidence that your devices will be updated by a trusted party.

You can read more on our FAQ. Our customer case studies also detail why Mender is

chosen for secure and robust OTA updates.

Architecture

ANALYSIS




Mender is a client-server application, where the client is installed in embedded devices

running Linux. The Mender client regularly checks with the Mender server over HTTPS

to see if it has an image update available for deployment, and deploys it if there is. A

dual A/B rootfs partition layout ensures robustness, so that the embedded device can

recover even during incomplete or corrupted deployment installations.

The Mender management server is now published on GitHub for on-premise

installations. It is licensed under the Apache 2.0 license.

Partition layout and reliability

For reliability during the update process, Mender uses a dual A/B rootfs partition

layout. The Mender client daemon runs in user space in the currently booted rootfs

partition.

During the update process, the Mender client writes the updated image to the rootfs

partition that is not running and configures U-Boot to boot from the updated rootfs

partition. The device is then rebooted. If booting the updated partition fails, the

partition that was running is booted instead, ensuring that the device does not get

bricked. If the boot succeeds, Mender sets the updated partition to boot permanently

when Mender starts as part of the boot process.

As Mender downloads and installs the image, other applications on the device continue

to run as normal. The only time the device has downtime is during the reboot into the

updated partition, which typically takes a minute, depending on the device




configuration.

Persistent data can be stored in the data partition, which is left unchanged during the

update process.

Board support

Out of the box, Mender supports the Raspberry Pi 3 and BeagleBone Black. Mender also

supports several other devices through our community. Contact us with your board

information to find out more about integrating Mender with your custom board

6.6.2 We need a highly secure method to do update from a central server. Having this done

with USB would only be possible, using secure method of certificate exchange. But can

the USB ports otherwise used?

Analysis

6.6.3

6.6.3

6.6.4.

6.6.5.

6.6.6

6.6.7

6.5 Remote Setting with Dashboard/Graphical Admin Panel

6.5 Software Configuration Dashboard (Must be overworked King Frog)

Input:

Output: Graphical Dashboard

See

doublettes

6.5.1 Software Configuration File

The kiosk is highly configurable through a configuration file which is XML based.

All parameters related to ports, URLS, keys must be imputed into that configuration file

which is ciphered for more security.

The use of a file, and not a table in the database is debatable. However, since the

configuration data includes in a mandatory way database-related values, it makes sense

not to store them in the table.

That configuration file should contains among other parameters:

• the test parameters ( if the app is used for unit or alpha tests );

• the locations of important files and folders;

• the locations of the databases;

• the URLS for the credit card payment gateway. Backend ( database );

• parameters related to security( firewall, key management etc...);

• parameters related to file checker, integrity checker, etc....

• hardware related parameters




6.5.2

Attn. King Frog

6.5.3

6.5.3

6.5.4.

6.5.5.

6.5.6

6.5.7

6.5.8

6.5.9

6.5.10

6.5.11

6.5.12

End Low Level here




7.0 Secure Communication

Cryptographic protocols

7.0 Secure Communication

Input:

Output:

7.0.1 Https

The Kiosk will connect only to HTTPS server equipped with the EVENTOS certificate

server, eg servers provided with a special certificate issued by the EVENTOS certificate

authority server. These servers are also configured to accept only connections from

clients equipped with a eventos client certificate ( 'two-way SSL' )

It has to be noted that these certificates are not issued by verisign, komodo etc... but by

EVENTOS own authority for internal validation of the devices. EVENTOS authority

should be the only authority trusted by the kiosk.

That simple mechanism offers already a very good secure channel where information

are ciphered and where both sender and receiver are equally authenticated to each

others.

Only TLS 1.2 should be used for such secure channels since TLS1.0 has been proved

recently to be insecure ( BEAST attack etc...)

7.0.2 Proprietary Communication Format

The kiosk uses its own communication format to communicate with the kiosk server.

Basically each message contains a header with a timestamp, the sender and the

receiver.

Messages have basically three different natures:

– COMMAND ( a software command such as registering data , sending parameters )

– TRANSACTION ( a financial transaction )

– INFO ( info regarding the EFT POS , Diagnostic , ping etc... )

HEADER

FROM:KIOSK_ID/SERVER_ID...

TO: KIOSK_ID, SERVER_ID

TIMESTAMP: DATE in ms

SIGNATURE: DATA_SIGNED_BY_SENDER_PRIVATE_KEY

BODY_LENGTH: LENGTH_BYTES

CONTENT: ESPCOMMAND/INFO

BODY:

DATA_BASE64ENCODED_ENCRYPTED_BY_RECEIVER_PUBLIC_KEY(or

GROUP_COMMON_PUBLIC_KEY )

NOTE that if the message contains esp protocol command data they are ciphered by the

platform cipher (stream+aes) and that the messages travels in dual SSL tunnels.

If the message contains info such as diagnostics data (ram,disk...) they are not ciphered

by the platform.

Example:




<HEADER>

<FROM>14567AB00008</FROM>

<TO>700000</TO>

<TIMESTAMP>6789098765667670211</TIMESTAMP>

<SIGNATURE>VHlwZSAob3IgY29weS1wYXN0ZSkgc29tZSB0ZXh0IH

RvIGEgdGV4dGJveCBiZ

Wxsb3cuIFRoZSB0

ZXh0IGNhbiBiZSBhIEJhc2U2NCBzdHJpbmcgdG8gZGVjb2RlIG9yI

GFueSBzdHJpbmcgdG8gZW5j

b2RlIHRvIGEgQmFzZTY0Lg==</SIGNATURE>

<BODY_LENGTH>456</BODY_LENGTH>

<CONTENT>ESP_COMMAND</CONTENT>

</HEADER>

<BODY>

RGVjb2RlIGJhc2U2NCBzdHJpbmdzIChiYXNlNjQgc3RyaW5nIGxvb

2tzIGxpa2UgWVRNME5ab21

J

ekkyT1RzbUl6TTBOVHVlWVE9PSkNCkRlY29kZSBhIGJhc2U2NCBlb

mNvZGVkIGZpbGUgKGZ

vciBl

eGFtcGxlIElDTyBmaWxlcyBvciBmaWxlcyBmcm9tIE1JTUUgbWVzc

2FnZSkNCkNvbnZlcnQgdGV4

dCBkYXRhIGZyb20gc2V2ZXJhbCBjb2RlIHBhZ2VzIGFuZCBlbmNvZ

GUgdGhlbSB0byBhIGJhc2U2

NCBzdHJpbmcgb3IgYSBmaWxl</BODY>

7.0.3 There are up to 4 different layers of strong encryption that ensures total security of the

data containing financial orders between the POS and the backend.

If the message consists in INFO type, for example, CPU , performances data that are

uploaded from the POS to the backend , there won't be any additional encryption.

• 1st

layer: Dual SSL

This is the standard https protocol using a secure and modern algorithm ( eg TLS 1.1/1.2

/ PCI compliant algorithms )

• 2nd

layer: Messaging Encryption

This is the asymmetric encryption using PKI

• 3nd

layer: Stream cipher

This is a fast ultra secure stream cipher based on ISAAC

• 4th layer: Rinjdael block cipher

This is a secure 'modern' block cipher considered as unbreakable at the current time.

4 different levels of encryption corresponds to the reality of modern capacities to break

ciphers using various ways. The SSL1,2,3 and TLS 1.0 has been found insecure recently!

MUST BE

CHECKED,

May be

nonsense

7.0.3 Encryption system (See alsp page 37 on cVEND-Key Store presentation page 37

STATIC KEYS---- K_s : Key of the salt;

K_k: key of the rinjdael key;

K_h: key of the hash;

K_s2: stream cipher key.

ß----




RANDOM(32 bytes) from RNG -> Random

Hash(RANDOM (32 bytes) ,K_s) -> salt

Hash(RANDOM (32 bytes) ,K_k) -> key

Rinjdael(key,salt) -> Cipher

HASHMAC(SHA-1,K_h,K_k,Cipher) -> Hashmac

------------------------------------------ Random + Hashmac+ Cipher------------------------------------

stream cipher (K_s2)

---------------------------------------------------------- Cipher2 ------------------------------------------

Encryption is based on a Rinjdael cipher with key and salt been generated from static

keys and random number (unique to each session)

Then a Hashmac is computed from the cipher and concatenated.

The Random is also added to the message (mandatory for decryption on the other side)

Finally the whole message is ciphered again using a fast stream cipher (like ISAAC for

example) The system guarantees integrity and confidentiality. It has a double layer of

security

7.0.4. We do consider the bootabitlity or the update method via USB as a high risk as our

kiosk system is normally un-attented. Sot eh use of automated software loader to boot

the system is critical.

7.0.5. We should look at FEIG ELECTONIC CVEND Multi App transaction facility (presentation

page 38 NDA)

Separated applications running in distinct App Slots

- E.g. independent Open Loop and Closed Loop applications

- Each application can sign its own application (option)

7.0.6 Secure Linux (page 34 cVEND Feig electornic

Secure Boot

- Terminal firmware is cryptographically signed by Eventos

- Only signed update packages are accepted for any Update

Access Control

- Sensitive services are restricted to signed aplications

- Smartcard integraton vai EVS-11 board

- Tamper protected key store

- PKCS#11 compliant API (Cryptoki) for crypto opertions (See the Document:)

7.0.7

7.0.8

7.0.9

7.0.10

7.0.11

7.0.12




-.




7.1 Local Database

Cryptographic protocols

7.1 Local Database

Input:

Output:

7.1.1 Goal

The kiosk is provided with a local database. It can be a no-SQL database or a lightSQL

database.

That database shall store :

• all parameters from the configuration file;

• diagnostic data;

• Events log;

• Copy of transactions ( to be cyclically flushed );

• Some keys and passwords;

• Some resources ( images , files etc...);

7.1.2 local database design

DIAGNOSTIC TABLE

DATE CPU RAM DISK RAM_TOTAL DISK_TOTAL

Date of CPU used by Ram used by Storage used Total of Total of storage

the processes processes ram

sampling

7.1.2.1 NETWORK TABLE

EVENTS TABLE

CONFIG TABLE

USERS TABLE

TRANSACTIONS TABLE

SECURITY TABLE

FIREWALL TABLE

7.1.3

7.1.4.

7.1.5.

7.1.6

7.1.7

7.1.8

7.1.9

7.1.10

7.1.11

7.1.12




7.2 PKI (by King Frog) to be reviewed

Certificates

This section must be reviewed. It may not important for the MVP product, but it must be considered, that for the

enrolment we will use smart cards in a setup to secure our operation and to authenticate a kiosk or any in-store servers of

EVENTOS. See also the Hardware Specification/Firmware for the EVS-11 Secure Smartcard Board.

Remark: King Frog was working for some years in smart card development, so this is may be the only field he has some

useable knowledge.

7.2 PKI

Input:

Output:

7.2.1 The kiosk gets certificates from a certification authority operated by EVENTOS.

Basically the kiosk will be provided with a certificate identifying a store operated by a

shop. A shop may operate several kiosk and 1 kiosk = 1 store

7.2.2 Enrollment

Each time a new shop/store is created, certificates are been created for that shop by the

EVENTOS CA.

That enrollment is done from a form ( software/web ) where all data from shop are

filled.

When a kiosk is removed from a shop, the certificates are removed from the kiosk

memory.

The certificates allows to identify a given shop. Besides this a hardware signature that

uniquely identify the kiosk machine is computed. The couple certificate/hardware

signature allows to identify and authenticate a given kiosk machine belonging to a given

shop/store




7.2.3 Key Management

The EVENTOS kiosk uses two different key management to fetch the keys that will be

used for encryption/decryption: DUKPT and SmartCard.

DUKPT

The kiosk shall use a BDK ( Base Derivation Key ) commonly used in all kiosks and server

and stored in secure memory.

Smartcard via PKCS (See info on EVS-11 Secure Smart Card Board by Eventos)

Keys are stored in the smartcard memory. They are fetched from the smartcard by the

EFT at startup and securely stored in RAM. The smartcard can be considered as a

HSM.

7.2.4. The smartcard should also be used as a way to load the store certificates in the kiosk

memory. It should contain all the parameters needed to identify a shop. If a Pos has to

be recycled, it can be done easily by collecting the old smartcard or disabling it and

giving a new smartcard to the new owner.

Phase I: enrollment : a shop is been enrolled by creating a CRT from a web form by an

operator/administrator , then certificates are issued from the EVENTOS authority for

that shop/store. The certificate are stored into the smartcard as well as other

personalization data ( smartcard enrollment )

Phase II: use : the shop/store insert the smartcard in the kiosk reader and thus initialize

the kiosk with its data : this allows the kiosk to identify itself on the network of the




kiosks. All transactions are also signed by the certificates and then provide an irrefutable

proof of the identity of the kiosk … as well impossiblity to misuse the kiosk without

owning the smartcard – which is under the sole responsibility of the store/shop.

Note1: the smartcard reader should be provided with a lock so that the customer may

not withdraw it

Note2: In that configuration the kiosks cannot be used without a smartcard.

Thereforer without a valid smartcard they are inoperative and ciphered.

Phase III: end of use: the shop/store returns or destroy the smartcard . The kiosk

hardware can be simply used by an other shop/store with a different smartcard without

any modification or re-personalization!

7.2.5.

7.2.6

7.2.7

7.2.8

7.2.9

7.2.10

7.2.11

7.2.12




Boot Loader

Requirement Bootloader

7.3 Development Requirement For Linux, the two most common boot loaders are known as LILO (LInux LOader) and

LOADLIN (LOAD LINux). An alternative boot loader, called GRUB (GRand Unified

Bootloader), is used with Red Hat Linux. LILO is the most popular boot loader among

computer users that employ Linux as the main, or only, operating system. The primary

advantage of LILO is the fact that it allows for fast boot-up. LOADLIN is preferred by

some users whose computers have multiple operating systems, and who spend

relatively little time in Linux. LOADLIN is sometimes used as a backup boot loader for

Linux in case LILO fails. GRUB is preferred by many users of Red Hat Linux, because it is

the default boot loader for that distribution

7.3.1

7.3.2

7.3.3

-

-




Development Requirements by Vitality GmbH

Redmine, Github, Test Environment

I. Development Requirement

I.I For project management and task control we will use exclusively redmine.

Our redmine for EVENTOS is to be found under this URL:

https://eventos-dev.com

I.II For code repository we will use Github or SVN. Preferably Github.

I.III For time control (if applicable) we use either Upwork or Hubstaff.

I.VI Please specifiy each task when it is ready for testing.

I.VII Toolchain

- GNU Compiler

-

I.VIII Operating System:

- Linux kernel (4.xx)

- Root file system: t.b.d.

I.IX PCI PTS consideration

I.X

I.XI




More Infos and Links

http://porteus-kiosk.org/download.html

http://www.mender.io

www.denx.de/wiki/u-boot/

www.kernel.org

Tools

buildroot







eVENTOS Hardware Description

FLOOR standing model, 32”-inch portrait mode monitor.

Document: Eventos Hardware Requirement_v 0.7




REMARK:

Note all function parts are relevant or defined yet.




API

API Specification – Draft (based upon S……X)

Introduction – This is a sample- Definition must be made!

Disclaimer: Copyright for this Draft is by ShelfX, which is a competing company in the United States.

Document is freely available.

The EVENTOS point of sale system for managing merchandising fixtures, that do allow at the shelf

purchasing by consumers, who have a EVENTOS account and an associated NFC device for personal

identification. The NFC or Bluetooth LE identification device is associated with the consumer’s

EVENTOS account [Prepaid or back-to-back with bank account.

The software system provides an Application Programming Interface [API], that can be used to

build software applications that can enhance the user’s experience or the merchant’s ability to

manage their business. We might integrate devices of S….X within our markets.

The EVENTOS API is a RESTful JSON API. The API is divided into three components; 1) The

Configuration API is used to access and update aspects of locations, fixtures, shelves, devices, and

employees, 2) The Merchant API is used to access and update products, planograms, pick lists, sales

reports, etc., and 3) The VitalityCard API is used to access and update information relating to

consumers and their shopping history.

API Keys

API keys are assigned to employees and associated with their login. Each employee created in the

Configuration application automatically is assigned an API key. By associating API keys with

employees, it is possible to limit access to parts of the API based on permissions associated with the

Employee Type.

The system administrator (using the master account login) can define Employee Types in

Configuration. In defining a new Employee Type, the administrator can choose the Access Rights

associated with that Employee Type. The a new Employee can be defined using that Employee Type

and the new Employee will be assigned an API key that only allows access to parts of the system

allowed by the associated Access Rights.

The Employee’s API key is displayed as part of the employee profile.

Configuration API

The Configuration API allows programmatic access to the EVENTOS Configuration application at

yourdomain.config.EVENTOS.com.

List of Objects

Location

Fixture

Device

Shelf

Employee




Examining the API

Use a tool like POSTMAN REST [https://www.getpostman.com/ ] client to examine the ShelfX API.

There’s also a POSTAMAN Chrome plugin available at the Google Chome webstore. When using this

tool, set headers for “contenttype” and “accept” to application/json.

API Call Structure

The basic structure of a call is as follows:

https://config.(s....x).com/<object name>?account_id=<account id>>&key=<account

key>&domain=<company domain>&[<property 1=<property 1 value>>[&]]*&list=true

*There can be zero or more properties used to qualify the object being accessed. The specific

properties depend upon the object being accessed and are listed in the following subsections.

Difference in Business Logics

S…X has a system of a weight sensor in combination with a NFC triggered locking system mounted in

standard size fridges.

EVENTOS will serve and operate a software suite for:

Self-check-out kiosk and Mobile Apps

Self-check-out price tabs and Mobile App

Self-check-out cabinet/fridges (similar)

Parcel Locker Systems

Pre-Order Restaurant Services as Kiosk and Apps.

Details of the S…..X API may be found in our Dropbox/Redmine repositories.




Date post:	17-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Software Requirements Document - Linux_LL... · The kiosk will be the entry point to scan products,...

Documents