Покажи Публикации - gat3way
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: 1 2 [3] 4 5 ... 409
31  Сигурност / Системна Сигурност / Re: Искат да слагат RFID чипове в новите паспорти -: Апр 12, 2016, 01:53
Табакерата няма да помогне ако някой слухти близо до мястото където по принцип трябва да ти я четат, на мен примерно това в блъсканицата да ходя да чета чужди карти ми се вижда сложна идея, къде по-добре е да седна да си пия кафето достатъчно близо примерно до чекина на терминала с железарията за целта скатана в раницата. Поне звучи по-законспирирано.
32  Сигурност / Системна Сигурност / Re: Искат да слагат RFID чипове в новите паспорти -: Апр 10, 2016, 16:56
Неведоми са пътищата на шумящите гадове, те сами по себе си може да не са силни източници, но да си имат подходяща "антена" с която да пръскат боклук - кабелите навързани към тях. Етернет кабелите примерно или пък захранващите кабели от някой импулсен адаптер и накрая става така че самият "генератор" на шум може сам по себе си да е далече, но "антената" му да е доста по-близо.
33  Сигурност / Системна Сигурност / Re: Искат да слагат RFID чипове в новите паспорти -: Апр 10, 2016, 14:10
Някой хардуерен човек трябва да се изкаже по този въпрос, но доколкото знам, колкото и силно да облъчваш тага, той еднакво силно ще си излъчи каквото има да излъчва. Но пък "зареждането" от "по-далеч" изисква мощността на "зареждащия предавател" да нараства на квадрат спрямо разстоянието и от няколко сантиметра до примерно 10 метра спокойно може да се окаже че ти трябва доста обемна и енергоемка железария, за да "светнеш тага". А може и да не е така, знам ли.

Има и друг фактор - поне тези тагове дето оперират на КВ обхвата (които май са масовите по разни карти за градски транспорт и за контрол на достъпа в момента) - условията при които можеш да четеш отдалеч варират ужасно много. Всичките домакински електроуреди имат навика малко или много да серат там, някои неща (монитора и захранването на лаптопа на жена ми примерно) - създават брутален шум - трябваше да взема един screenshot когато са включени да видиш разлика (предполагам на "водопада" сигнала от тага щеше да е тотално удавен в шум). Примерно на едно летище е пълно с дисплеи, компютри, всякаква техника и ще е доста по-сложно да четеш отдалеч.

34  Сигурност / Системна Сигурност / Re: Искат да слагат RFID чипове в новите паспорти -: Апр 10, 2016, 01:25
Проблемът е че криптографията на тези неща когато я има обикновено е слаба - като например поточен шифър с 48-битов ключ, а ограниченията идват от консумацията на енергия, те не че не могат да направят по-"умни" тагове иначе. Вероятно това ще се подобрява с времето де.
35  Сигурност / Системна Сигурност / Re: Искат да слагат RFID чипове в новите паспорти -: Апр 09, 2016, 21:26


Това малкото е сигнала от MIFARE карта изчетена на разстояние около 5 метра, обаче не знам дали има достатъчно висок SNR, за да се декодира до нещо смислено, нямам и време да си играя. И да стане, няма да е много практично, тя антената е доста обемна и сигурно дори няма да ме пуснат в някое летище с нея :)

С dedicate-ната за целта приемна система сигурно може да се направи далеч по-ефективно. Макар че пасивното изчитане е едно, да го накараш да предава е друго.
36  Linux секция за начинаещи / Настройка на програми / Re: Ограничаване на нета ако ИП-то не е дадено от DHCP сървъра. -: Апр 06, 2016, 01:32
Кауза пердута е това без умен суич с dhcp snooping или 802.1x автентикация. Човек ако го прави нарочно това, винаги може да слухти известно време трафика и да разбере колкото си иска двойки IP-MAC адреси и да се прави на когото си иска. Да, то може да си инсталираш arpwatch или нещо друго подобно, което на момента да те уведомява като се получат дуплицирани ARP отговори, ама какво от това - ще ходиш по суичовете и ще разкачаш кабели докато намериш гадината? Дори на всеки порт да имаш лепенка с MAC адреса отсреща, дори да си правиш тънки сметки с това през колко суича до теб е на база латентността, не можеш по цял ден да стоиш като сотаджия на повикване. То не е проблем само с малките доставчици - аз имах един казус с Мтел дето ми взеха едни пари уж за да ме вържат в мрежата и не дойдоха две седмици, а междувременно се оказа че аз винаги съм си имал L2 свързаност, при което ми изпуши главата и отидох и им заявих в съпорт форума че ако не ми дадат мрежови настройки и не ми върнат таксата, ще почна да се правя на който реша, понеже те и да са голяма компания, също нямат умни суичове при крайните клиенти, поне тук. То там дори стана по-къдраво, защото се появи един трол дето си мисли че е по-голям трол от мен, ама нещо не се получи, за това си трябва талант. Още на същият ден обаче се уреди проблема.
37  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 30, 2016, 02:08
Изглежда по-красиво ако не друго :)

Цитат
  Добре де,приемаме ,че много печен хакер е прихванал ключовете и т.н.
   Ако обаче се използват ТАН-ове (някои банки ги използват в интернет
банкирането си),предварително договорени последователности от числа,
хакера тогава нищо не може да направи (няма как да знае следващото
число),тогава ще трябва да хакне сървъра ,или някой клиент.
   Подобна имплементация според мен е доста сигурна.

TAN-овете са средство за автентикация, не за осигуряване на конфиденциалността на комуникацията, но да речем може лесно да се пригоди вместо поредни номера, по сигурен канал да се разменят направо поредица сесийни ключове. Ключове ще предоставя, но иначе тъй като проблемите са различни и има различни изисквания, ще има други драми. Например, само по себе си пак няма да реши проблема с replay атаките - да хванеш и да изпратиш същото (криптирано) съобщение втори път. Няма да ти реши проблема с елементарната DoS атака ако имаш някой в средата който нарочно да модифицира съобщения, да ти "изхаби" целият договорен списък със сесийни ключове и да те прати пак по бюрократичните мъки. Ти също така никога няма как да знаеш с кого си говориш - освен по това че криптираните съобщения, които ще ти праща са пълен булшит ако той не знае ключа, но този пълен булшит може и да се интерпретира по някакъв начин, все пак машините са тъпи и поемат каквото им дойде. За последното има решение ако се ползва автентицирано криптиране или HMAC, така че това да речем не е големият проблем.

Големият проблем както казах е че това няма да скалира добре. В случаят с банкирането си улеснен - първо защото се предполага че можеш да си го вземеш от твоя банков клон срещу молба и лична карта и цялата бюрокрация, която е чисто "човешка" работа. Подобен лукс обаче трудно би могъл да имаш ако примерно разработваш приложение за криптиран чат (представи си сходна схема, само че със скайп примерно). И просто е неудобно. Ако искаш представи си го като HTTPS сайт за който вместо да се доверяваш на цялата CA йерархия там, ходиш и изискваш отнякъде (дали на крака в офис, дали по пощата) списък с ключове. Докато не ги получиш (и това отнема време), не можеш да се свържеш. Като ги изчерпаш, съответно същата процедура. Хората биха намразили нещо такова :)
38  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 27, 2016, 16:04
Цитат
   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.

Това не работи така. Той TCP стека по принцип няма да"асоцира" с връзката пакет идващ от друг IP адрес и съответно нищо няма да се изчете от сокета, така че няма нужда от iptables правила. Обаче както BRADATA спомена, в същия етернет сегмент не е проблем да се правиш на който и да е, решенията срещу тези проблеми (порт секюрити, 802.1x) не са толкова евтини и лесни за прилагане. Ако трафикът се рутира през инфраструктура контролирана от лошите (да речем доставчика ти), тогава също няма как да знаеш с кого си говориш, всичко ще изглежда нормално. Дори не говорим за големите конспирации - претуриране на чужд трафик чрез BGP измами, tap-ване на оптични кабели и съвсем "легално" разположената из разни IX-ове и tier1 телекоми техника за слухтене и селективно mitm-ване на разни врази там.
39  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 26, 2016, 02:33
Ужасно е досадно подържането на CA, поне от скромния си опит, доста ограничен до само няколко хоста. Тогава ползвах xca, не знам сега дали има нещо по-удобно и красиво. С конзолните tool-ове на openssl е....мех, трябва да си ненормален / най-малкото да изпишеш прилично скриптове да ти организират нещата. Като по-млад и по-глупав обичах да се изцепвам че работата на CA-тата е лесна и правят пари от нищо, обаче далеч не е така, в такъв мащаб като техния това е доста комплексна и досадна кочина. Извън всички одити, процедури, клиентски там фронтенди, OCSP и timestamp verification инфраструктура и прочее дивотии, изискванията към CA-тата са брутални. Например на "най-най-root" сертификата, частният му ключ не се пази на никой хост, а е split-нат на няколко физически носители, които стоят в различни сейфове до които имат достъп различни хора - оттам надолу по веригата следващите като тръгнат да изтичат се събират хората, вадят флашките и подписват следващият генериран csr, процесът се документира надлежно....и машината на която е подписан intermediate сертификата....се разрушава, защото знае ли човек може някъде по случайност да остане събрания ключ. Това съвсем сериозно, такава параноидна шизофрения е там и такива са им процедурите.

Та нуждата от доверена трета страна определено е нещо което бърка в задника...обаче не мисля че има адекватно решение, което да се скалира добре, в смисъл може и без доверена трета страна разбира се, но това става в ограничени мащаби точно както примерно можеш да си набиваш и хостове в /etc/hosts и това работи в ограничени мащаби, иначе много скоро стигаш до нуждата от DNS протокола.

То не е и толкова технически въпрос, колкото не знам, логически/философски там. В реалният живот е същото, затова примерно като някой прави нещо вместо теб с пълномощно, обикновено го искат нотариално заверено....защото на този някой не му вярват, но на нотариуса му вярват. Въпросите с доверието са винаги такива забавни, защото хората както имат навика да лъжат, така имат навика и да се доверяват на базата на някакви ирационални критерии, а пък абсолютно всичко си се гради на доверие - обществения строй, икономическата система, всичко можеш с добро желание да го сведеш до отношения на доверие.  И оттам съществува и ирационалното схващане че технически тези неща могат да се решат някак си, спестявайки си съвсем логическите дилеми. Само че поне досегашният опит показва че не стават толкова лесно нещата.

Иначе кандидати да се замени PKI като идея има, не като да няма, примерно разни IBE схеми, само дето и там има трета доверена страна, там някои (скъпи) проблеми се решават, други (неприятни) проблеми се въвеждат. При kerberos понеже се спомена, сървърът дето издава ticket-ите e и третата доверена страна. Чувал съм разни екзотични идеи, като например ползването на нещо подобно на блокчейна в биткойн като убиец на PKI и CA инфраструктурата и там идеята за доверената трета страна е леко размита. Обаче на мен ми се вижда като цяло глупаво хрумване, ма па знам ли - може да се доразвие и да добие смисъл.
40  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 22, 2016, 02:49
Ми ти на 2) нямаш вече установен чрез DH ключ. В смисъл кой ти е казал че е установен, аз поне не бих се съгласил особено в mitm сценария.
41  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 22, 2016, 00:15
Diffie-Hellman без значение дали е с фиксирана или с ефемерна публична стойност, по дефиниция е податлив на mitm атаки, т.е ако някой стои между двете страни няма никакъв проблем да представи собствена публична стойност, сметките да минат и да сдоговорят с двете страни два, макар и различни, но известни на атакуващият сесийни ключове.

Сега ако въпроса е защо след като е уязвим въпреки всичко се ползва в TLS или SSH протоколите примерно, това е защото не се ползва само DH, малката тайна е че сървъра там подписва публичната си стойност и клиентът проверява сигнатурата, при това положение няма как някой по средата да мами. Обаче това вече влачи и последствията като например нуждата клиента да има налични публични ключове (или сертификати) срещу които да проверява дали това отсреща е сървъра с който иска да си говори или не, и тези трябва по някакъв сигурен канал да му бъдат доставени. В случаят с SSH това обикновено не се случва (първият път когато се връзваш ти се вади fingerprint-а на сървърния ключ и ако искаш връзваш, ако не искаш - не - но ако вържеш оттам нататък се помни и при промяна реве). Сега обаче в 99.999% от случаите на никой не му пука да проверява това, което е разбираемо - излишна параноя, а човек бърза да си свърши работата в крайна сметка.


Та както и да е - оттук и идея - няма ли да е далеч по-лесно да ползваш готова (и доказана) TLS имплементация, вместо сам да си измисляш криптосистема (което не е лесно и е твърде вероятно да се оплеска) ? С PyOpenSSL примерно не е толкова сложно, има и примери из нета. "Стандартната" ssl библиотека на питон е дори още по-лесна за ползване, единствено не дава достъп до разни неща, които с много голяма вероятност изобщо няма да ти трябват.
42  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 21, 2016, 14:22
Ми тя такава схема би била податлива на MitM атака - примерно аз стоя по средата и първоначално раздавам на двете страни моя публичен ключ, вместо да им препредам публичните ключове които са изпратили - оттам нататък всичко което минава като комуникация ще мога да го декриптирам. Всъщност, ще мога дори да криптирам каквото ми изнася с моя частен ключ и да го предам нататък, вместо да препредам оригиналното съобщение, то ще си изглежда съвсем легитимно.
43  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 21, 2016, 12:34
Че това си е доста. Например откъде ще се взема ключа за криптирането. Само конфиденциалността ли е цел, интегритета на данните важен ли е, някаква форма на автентикация между двете страни ще има ли или те ще си вярват една на друга по подразбиране - тези неща не са нищо особено.
44  Програмиране / Общ форум / Re: Криптографска библиотека -: Мар 21, 2016, 00:40
Това би трябвало да е от предпоследните въпроси, няма особено значение каква библиотека използваш, далеч по-важно е какво ще правиш.

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

45  Хумор, сатира и забава / Живота, вселената и някакви други глупости / Re: Vocoder-и за линукс? -: Мар 17, 2016, 12:34
Може, C++ API-то не е много сложно, аз съм си правил собствени блокове. Има и документация и някакви скриптове дето ти създават първоначалния проект с наготово класовете, билд скриптовете и xml-ите дето описват блока, остава само да напишеш методите и да си дефинираш входовете и изходите в xml-ите.

А иначе, stream_to_vector e "децимиращ" блок, т.е произвежда по-малко item-и, отколкото му идват и оттам двата му параметъра единствено контролират съотношението "входни item-и/изходни вектори", в повечето случаи няма смисъл да е нещо различно от 1, освен ако предполагам не те мързи да делиш. Не знам какво трябва да се случи ако вход делено на изход дава остатък, вероятно последният генериран вектор ще се пад-ва с нулеви стойности, никога не съм пробвал.

P.S примерен OOT gnuradio блок: https://github.com/gat3way/gr-ale  - можеш да видиш xml-а в grc/ и самата имплементация е в lib/decode_ff_impl.cc

Между другото е мърлява работа набързо колкото да сработи, примерно няма писани тестове, общоприетата именна конвенция не е спазвана 100%, xml-а не е попълнен по всички правила и почти нищо не е документирано, но пък онагледява горе-долу как изглежда нов custom блок.
Страници: 1 2 [3] 4 5 ... 409