Обеспечить защиту поддельных данных для конечных пользователей сервисных инструментов? - PullRequest
3 голосов
/ 11 марта 2019

Мне нужно создать сервис, но мне нужна помощь с выбором инструментов.

Представьте себе сервис, в котором пользователи создают некоторые данные, которые имеют ценность в историческом представлении (например, транзакции). Другие пользователи могут видеть эти данные, но им нужно подтверждение того, что данные являются реальными и не подделаны пользователями или даже службой.

Пример:

  1. Пользователь А создает запись с номером 42
  2. Пару месяцев проходит
  3. Пользователь Б видит эту запись и хочет быть уверен, что служба не может обновить эту запись с любым другим номером 37

Сервис имеет окно доверия с 24 часами: он даже может изменять данные пользователей, которые были сделаны в этот день.

Вопрос: Какие инструменты могут помочь мне достичь этого?


Я думал о том, чтобы делать публичные ежедневные резервные копии (или отчеты?), Которые может скачать любой пользователь. Из каждого отчета будет вычисляться хеш и вставляться в следующую резервную копию - таким образом, создается чан хешей. Если сервис что-то изменит в прошлом, то хеши в этой цепочке не сойдутся. Конечно, я создам инструмент с открытым исходным кодом для простого сравнения различий между данными и проверки правильности цепочки.

Точка доверия: есть одна вещь, которой я боюсь. Служба может использовать множество баз данных одновременно и обновлять все резервные копии со всеми хэшами один раз (поскольку первая резервная копия не имеет хеша предыдущего). Итак, чтобы охватить этот случай, я думаю о хранении хешей в каком-то месте, которое служба не может изменить вообще. Например, в одной из существующих блокчейнов (btc, eth, ...) из официального кошелька сервиса. Или, может быть, DAG с таким блокчейном, как IOTA?


  1. Что вы думаете о точке доверия?
  2. Могу ли я достичь своей цели более простым способом (без блокчейна)? А какой?
  3. Какие узкие места в этой логике?

1 Ответ

1 голос
/ 19 марта 2019

Здесь есть 2 участвующие переменные

  1. отметка времени, в которую создается запись.
  2. данные.

Раствор предпосылки,

  1. Доказательство взлома.
  2. данные могут быть изменены в тот же календарный день по Гринвичу без нарушения гарантии защиты от несанкционированного доступа. (может быть изменено на фиксированное окно после создания)
  3. СУБД как хранилище данных (можно изменить на любой NoSQL с незначительными модами, но идея остается прежней).
  4. Не зависит от какого-либо другого механизма, который может быть неисправен или подвержен ошибкам.
  5. Проверка одного запроса.

## Предлагаемое решение

создать таблицу данных

CREATE TABLE TEST(
ID INT PRIMARY KEY AUTO_INCREMENT,
DATA VARCHAR(64) NOT NULL,
CREATED_AT DATETIME DEFAULT CURRENT_TIMESTAMP()
); 

создать таблицу контрольных сумм, которая контролирует отпуск

CREATE TABLE SIGN(
ID INT PRIMARY KEY AUTO_INCREMENT,
DATA_ID INT NOT NULL,
SIGNATURE  VARCHAR(128) NOT NULL,
CREATED_AT DATETIME DEFAULT CURRENT_TIMESTAMP(),
UPDATED_AT TIMESTAMP
);

создать триггер при вставке данных

/** Trigger on insert */
DELIMITER //
CREATE TRIGGER sign_after_insert
AFTER INSERT 
ON TEST FOR EACH ROW
BEGIN 
-- INSERT VAL 
INSERT INTO SIGN(DATA_ID, `SIGNATURE`) VALUES(
NEW.ID, MD5(CONCAT (NEW.DATA, DATE(NEW.CREATED_AT)))
);
END; //
DELIMITER ;

Создать триггер для обновления данных

-- UPDATE TRIGGER
DELIMITER //
CREATE TRIGGER SIGN_AFTER_UPDATE
AFTER UPDATE 
ON TEST FOR EACH ROW
BEGIN 
-- UPDATE VALS
IF (NEW.DATA <> OLD.DATA) AND (DATE(OLD.CREATED_AT) = CURRENT_DATE() ) THEN
UPDATE SIGN SET SIGNATURE=MD5(CONCAT(NEW.DATA, DATE(NEW.CREATED_AT))) WHERE DATA_ID=OLD.ID;
END IF;
END; //
DELIMITER ;

Test

Шаг 1: вставить данные

INSERT INTO TEST(DATA) VALUES ('DATA2');

Подпись данных и дата их создания будут отражены в качестве подписи в таблице SIGN.

Шаг 2: обновить данные

подпись будет обновлена, если значение будет изменено, и это ЖЕ ДЕНЬ .

UPDATE TEST SET DATA='DATA' WHERE ID =1;

Шаг 3: проверка

вы всегда можете проверить подпись данных как

SELECT MD5(CONCAT (T.DATA, DATE(T.`CREATED_AT`))) AS CHECKSUM, S.SIGNATURE FROM TEST AS T ,SIGN AS S WHERE S.DATA_ID= T.ID AND S.`id`=1;

выход

| ПРОВЕРКА | ПОДПИСЬ | | ------ | ------ | | 2bba70178abdafc5915ba0b5061597fa | 2bba70178abdafc5915ba0b5061597fa

...