Security key. Where to store.

[MarkM]

Есть 3-х слойный веб апп. Браузер -> веб апп сервер -> БД.
Юзера хотят шифровать инфу, которая лежит в БД, фамилии, номера и тп. Типа засекретить данные от админов.
Я ДБА. Мне эти данные тоже видеть не полагается.
Я предложил шифровать в БД, что прозрачно для апп, но ключ давать извне.
Вопрос.
Где (и как) хранить ключ шифрования?
В БД я хранить не хочу, т.к. я им потенциально могу воспользоваться.
Хранить в Апп, веб-сервере - сисадмины могут докопаться.
Выход - раз ключ нужен юзерам - хранить у них на тонком клиенте.

Как?

[Marmot]

Вопрос, ключ один на всех, или у каждого свой?

[MikeD]

Вопрос: а как ты собираешься ключь передавать? Открывать SSL и делать полностью секьюрный коннекшен или просто слать бинарный файл при логине и кешировать ключ в сессии?

А вобще, это очень неуклюжее решение, да и скарость будет сильно страдать. У тебя прям шпионская параноя какая-то или это у клиента?
А как же люди держат базы данных с личной инфой, с кред. картами?

[Ivan]

Естественно что это не Марк параноей страдает а его клиент(работадатель, босс, whoever).

А если данные зашифровать не на ДВ сервере а на аппикатион сервере? Будет ли так быстрее?

[MarkM]

Пока пришли к идее:
Данне шифруются симметричным ключем (ключ данных, КД) по ДЕС3. Етот ключ лежит в БД зашифрованный приватным ключом РСА (ПК). ПК хранится в "сейфе". Паблик ключ (ОК) "устанавливается" на тонкие клиенты. С помошю ОК клиент, или Апп, рашифровывает КД и отдает его басе данных в качестве параметров для расшифровки-зашифровки.

Я пробовал датабазную част. Довольно быстро.
Повторяю, проблема только в том как хранить-манажить ето хозяйство ключей.

Да, КД один на всех. Да и паблик кеы тоже.
И еше. Весь трафик будет засунут в ССЛ.

[Marmot]

Пока пришли к идее:
Данне шифруются симметричным ключем (ключ данных, КД) по ДЕС3. Етот ключ лежит в БД зашифрованный приватным ключом РСА (ПК). ПК хранится в "сейфе". Паблик ключ (ОК) "устанавливается" на тонкие клиенты. С помошю ОК клиент, или Апп, рашифровывает КД и отдает его басе данных в качестве параметров для расшифровки-зашифровки.

Я пробовал датабазную част. Довольно быстро.
Повторяю, проблема только в том как хранить-манажить ето хозяйство ключей.

Да, КД один на всех. Да и паблик кеы тоже.
И еше. Весь трафик будет засунут в ССЛ.

Хм, с клиента ключик скопировать могут...

У меня есть другая идея

1. Берёшь токен, типа того, про который я тебе писал на кухне и инициализируешь его (у него внутри PKI computer:-) )
2. Генеришь симметричный ключ и ТУТ ЖЕ шифруешь его используя PUBLIC key из токена
3. зашифрованный ключ кладёшь на appserver
4. перед стартом appserver-а втыкаешь токен к нему в USB
5. На startupe appserver читает зашифрованный ключ, расшифровывает его используя PRIVATE key из токена и сохраняет в памяти.
6. Токен прячется к Большому Начальнику в сейф
7. Appserver может передать симметричный ключ в DB, или если захочет шифровать сам.
8. Возможность утечки ключа из appserver-а контролируется простым source code audit.

[MarkM]

[trn]
1. usera ne imejut fizicheskij dostup k serveru.
2. developery, i sysadminy, supportery potencial'no mogut imet' dostup.

hotelos'by reshenie na kliente, hotja by na odnoj tachke, Glavnogo Usera.

[/trn][/trn]

[Marmot]

[trn]
1. usera ne imejut fizicheskij dostup k serveru.
[/trn]

А им и не надо!

[trn]2. developery, i sysadminy, supportery potencial'no mogut imet' dostup.

hotelos'by reshenie na kliente, hotja by na odnoj tachke, Glavnogo Usera.

[/trn]

Ну и пусть, вытащить ключ из памяти - это надо ну очень сильно стараться, запускать appserver под дебагером с токеном в USB
Я не понял, чем тебе такой подход не нравится?
Токен нужен только в момент старта appserver-а, потом его убирают в сейф и всё...
Симметричный ключ из памяти хрен вытащишь, а для расшифровки нужен токен, который лежит в сейфе...

Правда в этом случае рестарт сервера превращается в этакую "торжественную" процедуру, но это даже лучше, начальство будет видеть, что без него ну никак

[MarkM]

[trn] nado razvjazat' restarty i uzerov. oni ne dolzhny zaviset'. da i vodit' "Glavnogo Uzera" v servernuju, ne solidno kak to, tem bolee esli oni v drugom rajone goroda.

luchshe skazhi, mozhno li skormit' kljuch v pamjat' app servera s klienta.
T.e. token vtykat' ne v server a v rabochuju stanciju Glavnogo Uzera.
Smozhet li brauzer zalezt' v token, vytashit' kljuch i otdat' App Serveru?[/trn][/trn]

[Marmot]

Тут имеются некоторые сложности.
Browser передаёт только сертификат, ключ можно туда засунуть как extention, но это плохо.
Можно использовать webservices, написать маленькую аппликуху (command line) которая открывает токен, достаёт PRIVATE key, посылает на сервер, который расшифровывает симметричный ключ.
Но это надо делать опять после каждого рестарта.

[MarkM]

-- Browser передаёт только сертификат, ключ можно туда засунуть как extention, но это плохо.


[trn]Pochemu ploho? Mozhno imet' 2 certifikata. 1-j dlja SSL sojedinenija, vtoroj kak konvert dlja simmetr kljucha. Esli Web App smozhet zaprosit' vtoroj sert, i vytashit' iz nego kljuch, to tak mozhno delat' ne tol'ko pri restartah no i pri kazhdom konnekte. Ja ne Java programmer, i ne znaju est' li tam API dlja zaprosa sertifikatov iz brausera. Dumaju est'.[/trn]

[Marmot]

-- Browser передаёт только сертификат, ключ можно туда засунуть как extention, но это плохо.


[trn]Pochemu ploho? Mozhno imet' 2 certifikata. 1-j dlja SSL sojedinenija, vtoroj kak konvert dlja simmetr kljucha. Esli Web App smozhet zaprosit' vtoroj sert, i vytashit' iz nego kljuch, to tak mozhno delat' ne tol'ko pri restartah no i pri kazhdom konnekte. Ja ne Java programmer, i ne znaju est' li tam API dlja zaprosa sertifikatov iz brausera. Dumaju est'.[/trn]

В Java есть API для доступа к сертификату который был использован для инициализации SSL connection, и только к этом сертификату.
т.е можно получить доступ только к тому, что засуното в это единственный сертификат.

А вообще сколько у вас юзверей-то?

[Ivan]

Марк, можно вопрос?

Можно ли этот ключ просто вписать в поле ввода на клиенте? т.е. на web form.

[MarkM]

[trl]marmotu.
userov eshe ne znaju skoka.

imho, esli dlja SSL soedinenija, kotoroe budet sekjurno, ispol'zuetsja sertifikat, to hranenie kljucha v takom sertifikate dostatochno sekjurno.
Pravil'no? Ved' tam vnutri vse zashifrovano?

Ivanu,
Teoreticheski da. Tak chto, zastavljat' usera kopi-pejst kljuch v eto pole?

[Ivan]

Только не смейся ладно...я тут все вникаю, потому что скоро мне надо будет тоже заняться безопасностью нашего проекта, а не для того чтобы тут крассоваться...

Вот такая еще идея: на маленьком CD (типа визитки) пишется ключ. На этом CD по аутозапуску запускается маленткая апликуха которая автоматом пишет этот ключ в то поле...