Нвк расшифровка сети: НВК. Наружные сети водоснабжения и канализации

Содержание

НВК. Наружные сети водоснабжения и канализации

Компания ООО «СЭР» занимается проектированием внутренних и наружных сетей водоснабжения и канализации.

Проектирование водоснабжения и канализации — это процесс разработки документации необходимой и достаточной для строительства сетей и сооружений водоснабжения и канализации. Начинается с утверждения технического задания и заканчивается авторским надзором за строительством. Результатом работы проектной организации является проектная документация в объеме 87 постановления правительства Российской Федерации или рабочая документация в объеме ГОСТов на соответствующие системы.

Проектирование систем водоснабжения

Проектирование наружного водопровода — это разработка проекта комплекса сооружений, самотечных и напорных сетей, служащий для забора воды из источников водоснабжения, ее очистки до нормативных показателей и подачи потребителю.

В ходе проектирования выполняется расчет расходов воды, подбор насосного оборудования, подбор оборудования очистки воды до требуемых показателей и разработка чертежей, соответствующих ГОСТам и нормативам.

Проектирование систем канализации

Проектирование наружной канализации — это разработка проекта взаимосвязанных сооружений, предназначенных для сбора, транспортирования, очистки сточных вод различного происхождения и сброса очищенных сточных вод в водоем-водоприемник или подачу на сооружения оборотного водоснабжения. Включает в себя канализационные сети, насосные станции, регулирующие и аварийно-регулирующие резервуары, и очистные сооружения.

Проектная документация по разделу водоснабжение и канализация выполняется в соответствии с действующими нормативными документами:: 1. Федеральный Закон от 22.07.2008г №123-ФЗ (в редакции от 10.07.2012г) «Технический регламент о требованиях пожарной безопасности»;; 2. Федеральный закон от 10 января 2002 г. № 7 –ФЗ «Об охране окружающей среды»;; 3. Федеральный закон РФ от 30 декабря 2009 г. № 384 «ТР о безопасности зданий и сооружений»; 4. Постановление Правительства РФ от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию»;; 5. СП 30.13330.2012 «Внутренний водопровод и канализация зданий»; 6. СП 31.13330.2012 «Водоснабжение. Наружные сети и сооружения»; 7. СП 32.13330.2012 «Канализация. Наружные сети и сооружения»; 8. СНиП 2.04.02.01-84 «Водоснабжение. Наружные сети и сооружения»; 9. СНиП 3.05.04-85* «Наружные сети и сооружения водоснабжения и канализации» (с изменениями)

Проектирование сетей НВК, НВК проект

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

Понятно, что проектирование сетей НВК для отдельного коттеджа и для промышленного предприятия будет значительно отличаться, как по объемам, так и по количеству согласований. Между тем, как выполнение требований СНиП и норм обязательно и в том, и другом случае.

Определяя объемы требуемого финансирования на строительство и монтаж сетей НВК, следует учитывать, что, если в состав сточных вод попадают нефтепродукты или жиры, при проектировании в обязательном порядке появится раздел «Локальные очистные сооружения».

Состав готового проекта может варьироваться от объекта к объекту, но в обязательном порядке в том или ином виде должны присутствовать следующие разделы: пояснительная записка, в которой при проектировании обосновывается принятие того или иного технического решения; расчетная часть, где приводятся гидравлический и прочностной расчеты; схемы и планы; деталировки отдельных узлов, ведомости и спецификации. По желанию заказчика при проектировании могут быть составлены сметы на монтаж сетей НВК.

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

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

Нередко заказчик испытывает затруднение в получении всех исходных данных. В таком случае проектная организация, занимающаяся проектированием сетей НВК, может взять эту функцию на себя.

Однако составить проект НВК недостаточно. Перед началом монтажа необходимо получить большое количество согласований. Это особенно актуально, если проектирование сетей НВК

велось для юридического лица. При заключении договора на проектирование необходимо четко оговорить, кто именно будет заниматься согласованием – заказчик или проектировщик, и отвести в календарном плане выполнения работ определенное время на получение согласований.

НВК — это… Что такое НВК?

НВК — национальная вещательная компания НВК «Саха» организация, Якутия НВК Нижегородская венчурная компания ООО организация Источник: http://is. park.ru/news.asp?dno=3642499&no=200899 НВК наружные сети водопровода и канал … Словарь сокращений и аббревиатур

НВК — ЗАО «Независимая Вещательная Компания» Страна … Википедия

НВК — нижние водяные коммуникации Термины атомной энергетики. Концерн Росэнергоатом, 2010 … Термины атомной энергетики

НВК — нижние водяные коммуникации нефт. с невысаженными концами non upset ends (NUE) … Универсальный дополнительный практический толковый словарь И. Мостицкого

НВК-банк — НВК НВКбанк НВК банк Нижневолжский коммерческий банк с 1990 ОАО http://www.nvkbank.ru/ г. Саратов, организация, фин … Словарь сокращений и аббревиатур

Национальная вещательная компания \»Саха\» (НВК \»Саха\») — Указ Президента Республики Саха (Якутия) Об уставе госучреждения НВК «Cаха» РС(Я) В целях приведения устава государственного учреждения «Национальная вещательная компания «Саха» Республики Саха (Якутия)» в соответствие с Гражданским кодексом… … Википедия

НВКбанк — НВК НВКбанк НВК банк Нижневолжский коммерческий банк с 1990 ОАО http://www. nvkbank.ru/ г. Саратов, организация, фин … Словарь сокращений и аббревиатур

Хлебный Дар — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/10 декабря 2012. Пока процесс обсужден … Википедия

БРАЗИЛИЯ — Федеративная Республика Бразилия, крупнейшее по площади и численности населения государство в Южной Америке. Бразилия на севере граничит с заморским департаментом Франции Гвианой, Суринамом, Гайаной, Венесуэлой и Колумбией; на западе с Перу; на… … Энциклопедия Кольера

Бразилия — 1) столица Бразилии. Новый город, построенный специально как столица гос ва Brasil, получил название Brasilia, производное от названия гос ва. На русск. язык название столицы передается с окончанием ия Бразилия, т. е. различия, имеющиеся в португ … Географическая энциклопедия

проект в категории Отопление/Вентиляция, 04.

02.2019 в 13:16 Требуется разработать разделы ОВ ВК ДУ АУПТ ВПВ НВП (отдельно Стадия П), и после прохождения экспертизы (Стадия Р) для объекта:
Одноэтажное складское здание с встроенно-пристроенным двухэтажным АБК.

Высота стеллажного хранения до 5,5 м.
Степень огнестойкости здания II.
Предметы хранения: легкая промышленность, товары народного потребления (не взрывоопасное).
Площадь складского помещения 1400 м2.
Площадь «Складская вспомогательная» 400 м2.
Площадь АБК (общая 2 этажа) 800 м2.

Требуется выполнить разделы стадия П:
1 (воздух и тепло)
— ОВиК «Отопление, вентиляция и кондиционирование»
— ДУ «Система противодымной вентиляции»
— ИТП «Индивидуальный тепловой пункт»

2 (вода и канализация общая)

— ВК «Водоснабжение и канализация»
— НВК «Наружные сети водоснабжения и канализации внутриплощадочные»
— ЛОС «Ливневая канализация. Локальные очистные сооружения»

3 (вода пожарная)
— Общая насосная станция пожаротушения для АУПТ, ВПВ, НПВ с резервуарами
— АУПТ «Система автоматического спринклерного водяного пожаротушения»
— ВПВ «Внутренний противопожарный водопровод»
— НПВ «Наружное противопожарное водоснабжение» (сеть гидрантов и резервуары)

Общий срок разработки всех разделов не более 6х рабочих недель, и еще 2 недели на корректировку замечаний Генпроектировщика.

Предпочтительно заключить договор с тремя разработчиками по направлениям: 1 Воздух и тепло, 2 Вода и канализация общая, 3 вода пожарная. Наружные сети НВК и НПВ желательно отдать в одни руки.

Экспертиза будет либо МосГорЭкспертиза, либо МосОблЭкспертиза, либо негосударственная экспертиза.

Прошу указать стоимости работ и сроки выполнения с учетом сопровождения ГЭ либо НГЭ до снятия всех замечаний по нашим разделам.

Оплата либо прямая, либо Безопасная сделка, так же предпочтителен договор подряда, если у вас ИП.

Слаботочные сети

Проектирование слаботочных систем

Учитывая все большее распространение всевозможных слаботочных систем, проектирование СС является на сегодняшний день необходимым процессом. В соответствии с нормами и правилами раздел «слаботочные сети» является неотъемлемой частью проектной документации для объектов строительства.
По техническому заданию Заказчика специалисты нашей организации профессионально выполняют разработку раздела Сети связи и Cлаботочные системы. Выполнение документации может осуществляться, как для комплекса слаботочных систем, так и для отдельных составляющих (например, систем безопасности).

Мы проектируем различные виды слаботочных систем

Телефонизация – выступает, как система современной телекоммуникации, с широкими возможностями голосовой передачи информации, как внутри объектов, так и ретрансляция на внешние источники. Сегодня широко применяется система IP-телефонии. IP-телефония позволяет использование любой IP-сети (Интернета, локальных сетей, выделенных каналов) в качестве средств телефонной связи, со всеми свойственными ей полезными свойствами, такими как ведение междугородних и международных телефонных разговоров или передача факсов в режиме реального времени.
Проектирование телефонизации включает в себя разводку сетей внутри здания, установку оборудования – АТС, а также наружные сети телефонной связи (воздушные линии или же кабель, проложенный в канализации).

Автоматические телефонные станции классифицируются, как аналоговые, цифровые и гибридные. Для небольшого количества абонентов используются мини-АТС. Как правило, в современном строительстве применяются цифровые системы, позволяющие использовать практически неограниченное количество сигналов, при этом абонентами могут выступать и аналоговые телефоны, и IP, и программные.

Интернет — трудно представить себе, что еще десять лет назад интернет для большинства из нас был чем-то особым, завораживающим, притягательным… Сегодня трудно представить себе здание, где бы не было проложено опто-волокна или не работал бы роутер, раздающий Wi-Fi сигнал на наши lapтопы. Проложить кабель, расставить точки доступа, определить характеристики сети — все это задачи проектировщика сетей WWW.

СКС — наша компания предлагает проектирование структурированной кабельной системы (СКС). Выполнение проектов осуществляется в соответствии с требованиями международного стандарта ISO/IEC 11801. Мы проектируем и подбираем оборудование в соответствии со стандартами и предпочтениями заказчика. Разработка рабочего проекта позволяет выполнять надежные и долговечные системы СКС. При проектировании системы СКС рассматривается и закладывается резерв для дальнейшего развития объекта, в результате чего, при организации новых рабочих мест или при осуществлении перепланировки, необходимость в прокладке дополнительных кабельных линий отсутствует.

Локальная вычислительная сеть (ЛВС) – данная система объединена одним или несколькими автономными высокоскоростными каналами передачи цифровых данных (в том числе проводными, волоконно-оптическими, радио-СВЧ или ИК-диапазона) в пределах одного или нескольких близлежащих зданий.

Радиофикация — передача звука на расстояние по средствам радиоволн. Сама система представляет из себя организацию внутри здания антенны настроенной на определенные радиочастоты. И хотя пользование радиоточкой в жилых домах уже постепенно стало атавизмом, тем не менее существуют объекты, для которых проектирование радиофикации обязательное явление, и системы настраиваются при этом на сигналы МЧС и других служб (характерно для промышленных объектов).

Кабельное телевидение – система кабельного телевидения предназначена для приема, обработки и передачи телевизионных сигналов по волоконно-оптическому или высокочастотному кабелю с целью их последующего распределения к потребителю.

Система видеонаблюдения – обеспечивает передачу визуальной информации о состоянии охраняемых зон, помещений, периметра и территории объекта в помещение охраны.
Данная система позволяет осуществлять не только контроль и запись наружного и внутреннего наблюдения, но также может быть интегрирована с системами контроля доступа и охранной сигнализации в единую целостную систему безопасности.

Система контроля и управления доступом (СКУД) – предназначена для обеспечения санкционированного входа в здание и в зоны ограниченного доступа и выхода из них путем идентификации личности по комбинации различных признаков: вещественный код (виганд-карточки, ключи touch-memory и другие устройства), запоминаемый код (клавиатуры, кодонаборные панели и другие устройства), биометрические признаки (отпечатки пальцев, сетчатка глаз и другие признаки), а также предотвращения несанкционированного прохода в помещения и зоны ограниченного доступа объекта.
Обеспечением контроля доступа на объект (для промышленных зданий) с недавних пор занимается технолог-проектировщик (Постановление Правительства №87 раздел Технологические решения).
Наша компания проектирует СКУД для промышленных объектов, офисных зданий, объектов специального назначения. СКУД позволяет решать и вопросы безопасности, и контроля рабочего времени персонала без привлечения большого количества дежурных и работников службы охраны, в некоторых случаях позволяет полностью автоматизировать процесс доступа на объект. Систему контроля и управления доступом возможно объединить в единую сеть управления инженерными системами здания или систему «умный дом».

Система охранно-тревожной сигнализации (СОТС) – представляет собой совокупность совместно действующих технических средств обнаружения проникновения (попытки проникновения) на охраняемый объект или зону помещений, сбора, обработки, передачи и представления в заданном виде информации о проникновении (попытки проникновения) и другой служебной информации.
Техническими средствами охранной сигнализации должны оборудоваться все помещения с постоянным или временным хранением материальных ценностей, а также все уязвимые места здания (окна, двери, люки, вентиляционные шахты, короба и т.п.), через которые возможно несанкционированное проникновение в помещения объекта.

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

Система оповещения о пожаре СОУЭ. Система оповещения создается для оперативного информирования людей о возникшей или приближающейся внештатной ситуации (аварии, пожаре, стихийном бедствии, нападении, террористическом акте) и координации их действий. Система также включает в себя функции по управлению эвакуацией людей.

Охранно-защитная дератизационная система (ОЗДС), предназначена для изгнания грызунов с территории объекта недвижимости и предотвращения их проникновения извне путем воздействия на них электрическим током высокого напряжения. Дополнительные факторы работающей ОЗДС – звуковое и электромагнитное излучение, а также наличие следов озона, которые воспринимаются грызунами как признаки предстоящего повторного электрического удара и способствуют отказу их от обитания на оборудованном объекте.

АСКУЭ – предназначена для автоматизированного контроля качества и учета потребляемой электроэнергии. Система АСКУЭ осуществляет сбор первичных данных по показателям энергопотребления для каждого объекта заказчика, рассчитывает, хранит и анализирует вычисляемые показатели, а также обеспечивает подготовку и выдачу необходимой информации для административного управления или на пульт предприятия ЭнергоСбыта. Система автоматически по телефонной линии или GSM каналу передает данные на пульт Энергосбыта, избавляя от необходимости снимать показания вручную. При помощи данной системы осуществляется контроль работоспособности приборов учета и оперативно обрабатываются данные по расходу электроэнергии.

Состав проектной документации « СМ-проект

Проектную документация для строительства принято разрабатывать в несколько стадий, Которые отличаются составом и глубиной проработки проектных решений. Основные требования к оформлению документации разных стадий изложены в ГОСТ Р 21.1101-2009.

Стадия 1 — ПП. Предпроектные проработки (Эскизный проект)

На данном этапе разрабатывается концепция будущего объекта, определяются основные технико-экономические характеристики. Эскизом определяется посадка объекта на местности, его объемно-пространственное решение, конструктивная схема. Также на данной стадии подсчитываются основные инженерные нагрузки по воде, теплу и электроэнергии, т.н. расчет нагрузок.

Разработка Стадии «ПП» не является обязательной, но помогает сэкономить время и средства при дальнейшем проектировании.

Стадия 2 — ПД. Проектная документация

В отличие от Эскизного проекта Стадия «Проект» («ПД» или просто «П») является обязательной и подлежит согласованию в государственных органах исполнительной власти. По результатам согласования Стадия «Проект» выдается разрешение на строительство объекта. Состав и содержание данного этапа регулируется Постановлением Правительства РФ №87 от 16. 02.2008. Безусловно, состав будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов и подразделов Стадии «ПД»:

Номер	Шифр раздела	Название раздела
Раздел 1		Пояснительная записка
Том 1	— ОПЗ	Пояснительная записка
Том 2	— ИРД	Исходно-разрешительная документация
Раздел 2	— ПЗУ	Схема планировочной организации земельного участка
Раздел 3	— АР	Архитектурные решения
Раздел 4		Конструктивные и объемно-планировочные решения
Том 1	— КР1	Железобетонные конструкции
Том 2	— КР2	Металлические конструкции
Том 3	— КР3	Деревянные конструкции
Том 4	— КРР	Статический расчет
Раздел 5		Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений.
Подраздел 1		Система электроснабжения
Том 1	— ИОС1.1	Наружное электроснабжение
Том 2	— ИОС1.2	Силовое электрооборудование
Том 3	— ИОС1.3	Электроосвещение
Подраздел 2		Система водоснабжения
Том 1	— ИОС2.1	Наружное водоснабжение
Том 2	— ИОС2.2	Внутреннее водоснабжение
Подраздел 3		Система водоотведения
Том 1	— ИОС3.1	Наружное водоотведение
Том 2	— ИОС3.2	Внутреннее водоотведение
Подраздел 4		Отопление, вентиляция и кондиционирование воздуха, тепловые сети
Том 1	— ИОС4. 1	Отопление и вентиляция
Том 2	— ИОС4.2	Теплоснабжение
Том 3	— ИОС4.3	Индивидуальный тепловой пункт
Подраздел 5		Сети связи
Том 1	— ИОС5.1	Телефония, Радиофикация, Телеприем
Том 2	— ИОС5.2	Структурированные кабельные сети
Том 3	— ИОС5.3	Автоматизация инженерных систем
Том 4	— ИОС5.4	Видеонаблюдение
Том 5	— ИОС5.5	Охранная сигнализация
Том 6	— ИОС5.6	Система контроля и учета доступа
Том 7	— ИОС5.7	Прочие слаботочные системы
Подраздел 6		Система газоснабжения
Том 1	— ИОС6. 1	Наружное газоснабжение
Том 2	— ИОС6.2	Внутреннее газоснабжение
Подраздел 7		Технологические решения
Том 1	— ИОС7.1	Технологические решения
Том 2	— ИОС7.2	Автоматизация технологических процессов
Том 3	— ИОС7.3	Воздухоснабжение
Том 4	— ИОС7.4	Холодоснабжение
Том 5	— ИОС7.5	Снабжение паром
Том 6	— ИОС7.6	Пылеудаление
Том 7	— ИОС7.7	Прочие технологические системы
Раздел 6	— ПОС	Проект организации строительства
Раздел 7	— ПОД	Проект организации работ по сносу или демонтажу объектов капитального строительства
Раздел 8		Перечень мероприятий по охране окружающей среды
Том 1	— ООС	Перечень мероприятий по охране окружающей среды
Том 2	— ООС. ТР	Проект технологического регламента обращения со строительными отходами на объекте
Том 3	— ИЭИ	Инженерно-экологические изыскания
Раздел 9		Мероприятия по обеспечению пожарной безопасности
Том 1	— ПБ1	Мероприятия по обеспечению пожарной безопасности
Том 2	— ПБ2	Автоматическая установка пожарной сигнализации, Система оповещения и управления эвакуацией людей при пожаре
Том 3	— ПБ3	Автоматика противопожарной защиты
Том 4	— ПБ4	Спецпожаротушение (водяное, порошковое и т.д.)
Раздел 10	— ОДИ	Мероприятия по обеспечению доступа инвалидов
Раздел 10(1)	— МЭ	Мероприятия по обеспечению соблюдения требований энергетической эффективности и требований оснащенности зданий, строений и сооружений приборами учета используемых энергетических ресурсов
Раздел 11		Смета на строительство объектов капитального строительства
Том 1	— СМ1	Смета на строительство объектов капитального строительства
Том 2	— СМ2	Мониторинг цен на материалы
Раздел 12		Иная документация в случаях, предусмотренных Федеральными законами
Том 1	— КЕО	Светотехнические расчеты инсоляции и естественной освещенности (КЕО)
Том 2	— ЗШ	Мероприятия по защите от шума и вибраций. Оценка шумового воздействия на период эксплуатации объекта
Том 3	— ИТМ ГОиЧС	Инженерно-технические мероприятия гражданской обороны. Мероприятия по предупреждению чрезвычайных ситуаций
Том 4	— ЭД	Инструкция по эксплуатации здания
Том 5	— ПТА	Мероприятия по противодействию террористическим актам
Том 6	— ДПБ	Декларация промышленной безопасности опасных производственных объектов

Стадия 3 — РД. Рабочая документация

Стадия «РД» нужна в первую очередь строителям, так как в ней наиболее полно и детально разрабатываются проектные решения, которые в Стадии «ПД» лишь обозначались. В отличие от «П», «Рабочка» включает в себя чертежи узлов, аксонометрические схемы и профили инженерных сетей, спецификации и т.п. С другой стороны, на рабочей стадии документация лишается некоторых разделов, полнота которых была исчерпана на стадии проектной (например, ПОС, ООС, КЕО, ИТМ ГОиЧС и т. п.). Как и на Стадии «П», состав «РД» будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов Стадии «Рабочая документация»:

Шифр раздела	Название раздела
— ГП	Генеральный план
— ТР	Сооружения транспорта
— ГТ	Генплан и транспорт (при объединении ГП и ТР)
— АД	Автомобильные дороги
— ПЖ	Железнодорожные пути
— АР	Архитектурные решения
— АС	Архитектурно-строительные решения (при объединении АР и КР)
— АИ	Интерьеры
— КЖ	Конструктивные решения. Железобетонные конструкции
— КЖ0	Конструктивные решения. Железобетонные конструкции. Фундаменты
— КМ	Конструктивные решения. Металлические конструкции
— КМД	Конструктивные решения. Металлические конструкции деталировочные
— КД	Конструктивные решения. Деревянные конструкции
— КРР	Конструктивные решения. Статический расчет
— ГР	Гидротехнические решения
— ЭС	Система электроснабжения. Наружное электроснабжение
— ЭМ	Система электроснабжения. Силовое электрооборудование
— ЭО	Система электроснабжения. Электроосвещение
— ЭН	Система электроснабжения. Электроосвещение наружное
— ЭИС	Электроснабжение инженерных систем
— НВ	Система водоснабжения. Наружные сети
— НК	Система водоотведения. Наружные сети
— НВК	Система водоснабжения и водоотведения. Наружные сети
— ВК	Система водоснабжения и водоотведения. Внутренние сети
— ОВиК	Отопление, вентиляция и кондиционирование воздуха
— ТС	Теплоснабжение
— ТМ	Тепломеханические решения (Котельная, ИТП, и т.п.)
— РТ	Телефония, Радиофикация, Телеприем
— СКС	Структурированные кабельные сети
— АИС	Автоматизация инженерных систем
— АТП	Автоматизация технологических процессов
— АК	Комплексная автоматизация (при объединении АИС и АТП)
— ВН	Видеонаблюдение
— ОС	Охранная сигнализация
— СКУД	Система контроля и учета доступа
— ГСН	Наружное газоснабжение
— ГСВ	Внутреннее газоснабжение
— ТХ	Технологические решения
— ТК	Технологические коммуникации
— ВС	Воздухоснабжение
— ХС	Холодоснабжение
— ПС	Снабжение паром
— ПУ	Пылеудаление
— АУПС — СОУЭ	Автоматическая установка пожарной сигнализации, Система оповещения и управления эвакуацией людей при пожаре
— АППЗ	Автоматика противопожарной защиты
— ПТ	Спецпожаротушение (водяное, порошковое и т.д.)
— СД1	Смета на строительство объектов капитального строительства
— СД2	Мониторинг цен на материалы
— АЗ	Антикоррозийная защита
— ТИ	Тепловая изоляция оборудования и трубопроводов

ГОСТ Р 21.1101-2009 Система проектной документации:
4.2. Рабочая документация
4.2.1. В состав рабочей документации, передаваемой заказчику, включают:
— рабочие чертежи, предназначенные для производства строительных и монтажных работ;
— прилагаемые документы, разработанные в дополнение к рабочим чертежам основного комплекта.
4.2.2. В состав основных комплектов рабочих чертежей включают общие данные по рабочим чертежам, чертежи и схемы, предусмотренные соответствующими стандартами Системы проектной документации для строительства (далее — СПДС).
…
4.2.6. К прилагаемым документам относят:
— рабочую документацию на строительные изделия;
— эскизные чертежи общих видов нетиповых изделий, выполняемые в соответствии с ГОСТ 21.114;
— спецификацию оборудования, изделий и материалов, выполняемую в соответствии с ГОСТ 21.110;
— опросные листы и габаритные чертежи, выполняемые в соответствии с данными заводов — изготовителей оборудования;
— локальную смету по формам;
— другие документы, предусмотренные соответствующими стандартами СПДС.
Конкретный состав прилагаемых документов и необходимость их выполнения устанавливаются соответствующими стандартами СПДС и заданием на проектирование.
…
4.2.8. В рабочих чертежах допускается применять типовые строительные конструкции, изделия и узлы путем ссылок на документы, содержащие рабочие чертежи этих конструкций и изделий. К ссылочным документам относят:
— чертежи типовых конструкций, изделий и узлов;
— стандарты, в состав которых включены чертежи, предназначенные для изготовления изделий.
Ссылочные документы в состав рабочей документации, передаваемой заказчику, не входят. Проектная организация, при необходимости, передает их заказчику по отдельному договору.

СНиП 11-01-95 Состав рабочей документации:
5.1. Состав рабочей документации на строительство предприятий, зданий и сооружений определяется соответствующими государственными стандартами СПДС и уточняется заказчиком и проектировщиком в договоре (контракте) на проектирование.
5.2. Государственные, отраслевые и республиканские стандарты, а также чертежи типовых конструкций, изделий и узлов, на которые имеются ссылки в рабочих чертежах, не входят в состав рабочей документации и могут передаваться проектировщиком заказчику, если это оговорено в договоре.

Сети теплоснабжения, тепловые сети

Главная > Корпоративным клиентам > Сети теплоснабжения. Тепловые сети >

Сети теплоснабжения (тепловые сети) – это система трубопроводов (теплопроводов), по которым теплоноситель переносит тепло от источника к потребителям и возвращается обратно к источнику.

Строительство сетей теплоснабжения регламентируется:
СНиП 41-02-2003 Тепловые сети.
СНиП 41-03-2003 Тепловая изоляция оборудования и трубопроводов.

В зависимости от источника тепла тепловые сети (теплосети) могут быть:
• централизованные – теплоснабжение от котельных, крупных и малых тепловых и атомных электростанций (ТЭЦ, ТЭС, АЭС).
• децентрализованные – теплоснабжение от автономных котельных, крышных котельных, модульных котельных, квартирных теплогенераторов.

В зависимости от схемы, устанавливаемой проектом или эксплуатационной организацией, тепловые сети могут быть:
• магистральные тепловые сети – транзитные сети, без ответвлений транспортирующие теплоноситель от источника тепла к распределительным теплосетям;
• распределительные (квартальные) тепловые сети — распределяют теплоноситель по выделенному кварталу, подводят теплоноситель к ответвлениям на потребителей;
• ответвления от распределительных тепловых сетей к отдельным зданиям и сооружениям.

В зависимости от транспортируемого теплоносителя тепловые сети делятся на:
— водяные тепловые сети (как правило, предназначены для коммунальных систем теплоснабжения)
— паровые тепловые сети (используются, в основном, в промышленных системах теплоснабжения)

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

По способу прокладки тепловые сети бывают:
• подземные – используются, как правило, в населенных пунктах
• надземные – на территориях промышленных предприятий и вне черты города

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

Надземная прокладка труб осуществляется на эстакадах или специальных отдельно стоящих опорах.

Для трубопроводов тепловых сетей следует использовать стальные электросварные трубы или бесшовные стальные трубы. При температуре воды до 150 °С и давлении до 1,6 МПа включительно допускается применять трубы из высокопрочного чугуна с шаровидным графитом (ВЧШГ). При температуре воды 115 °С и ниже при давлении до 1,6 МПа включительно допускается применять неметаллические трубы, если качество и характеристики этих труб удовлетворяют санитарным требованиям и соответствуют параметрам теплоносителя в тепловых сетях.

Наша организация предлагает следующие услуги и работы в сфере строительства тепловых сетей (ТС) * :

• Проектирование тепловых сетей
• Монтаж подземных теплосетей
• Монтаж надземных теплосетей
• Строительство теплотрасс (прокладка трубопроводов отопления)
• Монтаж теплопроводов и тепловых узлов
• Устройство гидро- и теплоизоляции тепловой сети
• Устройство системы ОДК
• Монтаж компенсационных устройств
• Монтаж запорной и регулировочной арматуры
• Устройство лотков и каналов
• Устройство неподвижных опор
• Устройство колодцев и тепловых камер
• Сборка и монтаж узлов учета тепла и систем диспетчеризации
• Установка тепловых пунктов — центральных тепловых пунктов (ЦТП) и индивидуальных тепловых пунктов (ИТП)
• Монтаж насосного и котельного оборудования системы теплоснабжения
• Демонтаж тепловых сетей
• Прокладка временных тепловых сетей
• Поставка оборудования и материалов для строительства теплосетей с учетом особенностей инженерных и архитектурных решений
• Получение разрешений и согласований при строительстве тепловых сетей
• Опрессовка и пуско-наладка сети теплоснабжения
• Ремонт и реконструкция тепловых сетей

* Узнать о стоимости работ Вы можете в разделе прайс-лист либо связавшись с нами по телефону (812) 309-23-57.

Исправление ошибки

Bitcoin Segwit может заблокировать доступ пользователей кошельков к их средствам

Вкратце

Независимый хакер обнаружил ошибку, которая влияет на криптокошельки, использующие протокол Segwit Биткойна.
Сама по себе уязвимость не так серьезна, как утверждают разработчики, но исправления для аппаратных кошельков могут заблокировать пользователям доступ к некоторым сторонним кошелькам.
Wasabi и BTCPay призывают пользователей перемещать средства с помощью своих Trezor перед обновлением устройства.

Чешский аппаратный кошелек Bitcoin Trezor два дня назад выпустил обновление прошивки. Патч был создан в ответ на потенциальную уязвимость для кошельков, использующих протокол Segwit — исправление транзакции, которое обеспечивает более дешевые и менее объемные биткойн-транзакции.

Но даже несмотря на то, что Trezor пропатчил свой кошелек, он по-прежнему вызывает проблемы у пользователей Trezor, которые полагаются на кошелек для взаимодействия с другим программным обеспечением, связанным с биткойнами, таким как кошелек Wasabi, ориентированный на конфиденциальность, и технологический стек Биткойн BTCPay.

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

Уязвимость

Известный независимый хакер Салим Рашид обнаружил эксплойт (последний из множества обнаруженных им аппаратных / программных ошибок Биткойн) около трех месяцев назад и раскрыл его крупным производителям аппаратных кошельков, включая Trezor и Ledger.С обновлением прошивки, доступным для загрузки, Trezor устранил уязвимость на своей стороне.

Но эта уязвимость, которую разработчики заявили Decrypt , будет сложно эксплуатировать, поэтому Trezor находится в центре внимания из-за его популярности среди интеграций сторонних кошельков (например, аппаратный кошелек может подключаться к популярному кошельку конфиденциальности Wasabi и порталу оплаты биткойнов BTCPay Сервер).

Фактическая ошибка, которая является более или менее серьезной, чем другие в прошлом, в зависимости от аппаратного кошелька и разработчиков программного кошелька, согласно Trezor, открывает следующие векторы атаки:

Пользователь Bitcoin, использующий Segwit, загружает определенную вредоносную программу от злоумышленника.Затем жертва начинает транзакцию с двумя «входами» (т. Е. Частями): один вход предназначен для 10 BTC, а другой — для 5 0001 BTC, поэтому общая сумма транзакции составляет 15 BTC с комиссией 0,0001. После подтверждения транзакции пользователь получает сообщение об ошибке с просьбой подписать еще раз. Затем злоумышленник переключает входы транзакции, так что один вход предназначен для 15 BTC, а другой — для 0,0001.

С этим переключателем теперь 15 BTC — это комиссия за транзакцию, а 0,0001 BTC — за транзакцию.Но для того, чтобы это окупилось, злоумышленник должен быть майнером , который также добывает блок, в который включена транзакция. Жертва также должна проводить транзакцию с более чем одним входом и загружают майнерское вредоносное ПО. Другими словами, должна пройти целую серию , чтобы это работало.

Производитель аппаратного кошелька ColdCard NVK, который не был проинформирован об уязвимости, упомянул, что атака «серьезность низкая», добавив, что обновление аппаратных кошельков может «нарушить взаимодействие аппаратного кошелька» с другим программным обеспечением кошелька.

Эта атака потребует наличия вредоносного ПО на компьютере или каких-либо других средств для изменения транзакции перед подписанием. А также требует, чтобы злоумышленник был майнером, чтобы получить выплату. Серьезность низкая, обновления могут нарушить взаимодействие HWI и, возможно, нарушить работу Core.
— NVK┗ (° 0◜) ┛ .. ○ ₿ (@nvk) 3 июня 2020 г.

Помимо потенциального преувеличения, Трезор сказал, что он упрощает решение проблемы. Генеральный директор Trezor Павол Руснак объяснил в своем заявлении: «Исправление простое — нам нужно работать с транзакциями Segwit точно так же, как и с транзакциями, не связанными с Segwit», что включает в себя проверку кошелька и повторную проверку всех его предыдущих транзакции перед отправкой новых.

Сопутствующий ущерб

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

Например, исправление (когда кошельки Segwit проверяют и повторно проверяют старые транзакции) не работает с некоторыми «сторонними инструментами».

«Trezor не сможет подписывать транзакции с помощью этих инструментов, пока они не будут обновлены для правильной работы. Из-за ответственного процесса раскрытия информации мы не смогли заранее проинформировать специалистов по сопровождению », — говорится в сообщении компании.

Одной из этих затронутых сторон является кошелек Wasabi, ориентированный на конфиденциальность, который в прошлом году интегрировался с Trezor. Основатель компании Адам Фискор, например, объявил в Twitter, что пользователям Wasabi не следует обновлять прошивку до тех пор, пока не будут решены «проблемы совместимости».

Если вы используете Trezor с Wasabi, пожалуйста, не обновляйте прошивку, пока не будут решены проблемы совместимости, иначе ваши средства застрянут, пока не появится поддержка новой прошивки. https: // т.co / zrA5ml2kBL
— nopara73 (@ nopara73) 5 июня 2020 г.

Фискор сообщил Decrypt по электронной почте, что, по его мнению, «последствия обновления прошивки, из-за которой пользователи Trezor заблокированы для кошелька [Wasab], более проблематичны, чем сама атака», и хотя он соглашается «с оценкой NVK, »Он не обвиняет Трезора« в излишней осторожности ».

Николя Дориер, основатель и руководитель сервера BTCPay с открытым исходным кодом, сказал Decrypt , что он хотел бы, чтобы Trezor предлагал «переходный период в 1-2 месяца, чтобы у пользователей было время для перевода своих средств.”

BTCPay Server — это децентрализованный платежный процессор биткойнов, который включает в себя дополнительные функции, такие как сеть Lightning, и, по состоянию на прошлый год, интеграцию аппаратного кошелька с Trezor.

Дорье сказал, что его сервису, вероятно, придется отказаться от поддержки Trezor и аппаратных кошельков, для которых требуется схема проверки транзакций, поскольку пользователи сервера BTCPay не хранят все данные блокчейна; они запускают так называемые «обрезанные» узлы, которые хранят ровно столько данных, сколько необходимо для использования услуг BTCPay в сети Биткойн (это ускоряет и упрощает загрузку и запуск BTCPay).

1 / Если вы используете Trezor и обновили прошивку, вы больше не сможете получать деньги со своего Trezor через сервер BTCPay. Мы не можем решить проблему, так как у нас нет данных, которые запрашивает Trezor. (без индекса транзакции) https://t.co/FIJOTiIHuD
— Сервер BTCPay (@BtcpayServer) 4 июня 2020 г.

Таким образом, как и Wasabi, BTCPay призывает своих пользователей не обновляться, чтобы их средства не были заблокированы сервисом. Пока пользователи используют старую версию Trezor, у них не должно возникнуть проблем с их удалением.Они также могут восстановить свои кошельки из исходной фразы (резервная фраза, которая действует как главный ключ к кошельку в случае его повреждения или утери) либо на другом аппаратном кошельке без исправлений, либо как новый кошелек на своем экземпляре BTCPay. .

На данный момент пользователям Trezor на Wasabi и BTCPay рекомендуется сидеть сложа руки и переводить свои средства перед обновлением.

Исправление ошибки

Bitcoin Segwit могло заблокировать доступ пользователей кошелька к их средствам — Расшифровать

Чешский аппаратный кошелек Bitcoin Trezor два дня назад выпустил обновление прошивки.Патч стал ответом на потенциальный подвиг для кошельков, использующих протокол Segwit — исправление транзакции, которое позволяет осуществлять более дешевые и менее интенсивные биткойн-транзакции.

Но даже если Trezor исправил свой кошелек, он по-прежнему создает проблемы для пользователей Trezor, которые полагаются на кошелек для взаимодействия с другим программным обеспечением, связанным с биткойнами, таким как кошелек конфиденциальности Wasabi и технологический стек Bitcoin BTCPay.

Из-за способа устранения уязвимости пользователи Trezor, которые обновляют и используют Trezor с Wasabi и / или BTCPay, будут исключены из своих средств.Wasabi и BTCPay призывают пользователей не обновлять, пока не будут решены проблемы совместимости между обновлением прошивки и их программным обеспечением.

Уязвимость

Известный независимый хакер Салим Рашид обнаружил эксплойт (его последнее открытие множества аппаратных / программных ошибок Биткойн) около трех месяцев назад и раскрыл его крупным производителям аппаратных кошельков, включая Trezor и Ledger. С обновлением прошивки, доступным для загрузки, Trezor со своей стороны исправил уязвимость.

Но эта уязвимость, которую, как заявили разработчики Decipher , будет трудно использовать, привлекает внимание к Trezor из-за его популярности среди интеграций сторонних кошельков (например, аппаратный кошелек может подключаться к популярному кошельку конфиденциальности Wasabi и платежный портал Bitcoin BTCPay Server).

Фактическая ошибка, которая является более или менее серьезной, чем другие в прошлом, в зависимости от портфеля оборудования и разработчиков портфеля программного обеспечения, согласно Trezor, открывает следующие векторы атак:

Пользователь Биткойн, использующий Segwit, загружает определенное вредоносное ПО от злоумышленника.Затем жертва начинает транзакцию с двумя «входами» (то есть монетами): одна запись предназначена для 10 BTC, а другая — для 5 0001 BTC, поэтому общая сумма транзакции составляет 15 BTC при затратах 0,0001. При подтверждении транзакции пользователь получает сообщение об ошибке с просьбой подписать еще раз. Затем злоумышленник переключает записи транзакции, поэтому одна запись предназначена для 15 BTC, а другая — для 0,0001.

С этим переключателем 15 BTC теперь являются комиссией за транзакцию, а 0,0001 BTC — транзакцией.Но для того, чтобы это принесло плоды, злоумышленник должен быть второстепенным , который также должен извлечь блок, в который включена транзакция. Жертва также должна провести транзакцию с несколькими записями. и загружают вредоносное ПО. Другими словами, для того, чтобы это работало, — много — должно идти правильно.

Производитель аппаратных кошельков ColdCard NVK, который не знал об уязвимости, заявил, что атака «серьезна» невысока, добавив, что обновление аппаратных кошельков может «нарушить взаимодействие аппаратного кошелька с другим программным обеспечением из портфеля».

Помимо потенциальных преувеличений, Трезор сказал, что он сохранил простое решение. Генеральный директор Trezor Павол Руснак заявил в своем заявлении: «Решение простое: мы должны обрабатывать транзакции Segwit так же, как и транзакции, не относящиеся к Segwit», что подразумевает, что кошелек проверяет и повторно проверяет все свои предыдущие транзакции перед отправкой новых единицы.

Сопутствующий ущерб

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

Исправление, например (попросить кошельки Segwit проверить и повторно подтвердить старые транзакции), не работает с некоторыми «сторонними инструментами».

«Trezor не сможет подписывать транзакции с помощью этих инструментов, пока они не будут обновлены для правильной работы. Из-за ответственного процесса раскрытия информации мы не смогли заранее уведомить ответственных лиц », — говорится в сообщении компании.

Одной из таких заинтересованных сторон является портфолио Wasabi, ориентированное на конфиденциальность, которое в прошлом году интегрировалось с Trezor.Основатель Адам Фискор, например, объявил в Twitter, что пользователям Wasabi не следует обновлять прошивку до тех пор, пока не будут решены «проблемы совместимости».

Fiscor сообщил Decipher по электронной почте, что, по его мнению, «последствия обновления прошивки, из которой исключаются пользователи Trezor [Wasab] кошелька, более проблематичны, чем сама атака», и хотя он согласен »с оценкой NVK, «Он не винит Трезора» в том, что он был слишком осторожен. «

Николас Дориер, основатель и глава сервера BTCPay с открытым исходным кодом, сказал Decipher , что он хотел, чтобы Trezor предлагал« переходный период от 1 до 2 месяцев, чтобы у пользователей было время для перевода своих средств ».

BTCPay Server — это децентрализованный платежный процессор биткойнов, который включает дополнительные функции, такие как сеть Lightning, а с прошлого года интеграцию аппаратного кошелька с Trezor.

Дориер сказал, что его службе, вероятно, следует отказаться от поддержки Trezor и аппаратных кошельков, для которых требуется схема проверки транзакции, поскольку пользователи сервера BTCPay не хранят все данные в цепочке блоков; они запускают так называемые «обрезанные» узлы, которые хранят ровно столько данных, сколько необходимо для использования сервисов BTCPay в сети Биткойн (что делает загрузку и запуск BTCPay быстрее и проще).

Итак, как и Wasabi, BTCPay призывает своих пользователей не обновлять, чтобы их средства не были заморожены в сервисе. Пока пользователи используют старую версию Trezor, у них не должно возникнуть проблем с их удалением. Они также могут восстановить свои кошельки из исходного предложения (резервное предложение, которое действует как главный ключ в кошельке в случае повреждения или потери) на другом неисправленном аппаратном кошельке или как новый кошелек на своем экземпляре BTCPay. .

На данный момент пользователям Trezor на Wasabi и BTCPay предлагается сесть и перевести свои средства перед их обновлением.

(PDF) Криптография в Интернете вещей

11. Imagination Technologies: Интернет вещей-устройства Возможности для дифференцирования. Проектирование и повторное использование

12. Камбодж Д., Гупта Д., Кумар А .: Эффективная эллиптическая кривая скалярного умножения

свыше. Международный журнал компьютерных сетей и информационной безопасности, 8 (4).

13. Канасе П. и Гайквад С .: Умные больницы с использованием Интернета вещей. Международный

Научно-исследовательский журнал техники и технологий.

14. Хан, М., Дин, С., Джаббар, С., Гохар, М., Гайват, Х., и Мукхопадхьяй, С.:

Контекстно-зависимый интеллектуальный маломощный SmarHome на основе Интернета вещей .

Компьютеры и электротехника.

15. Копец, Х .: Интернет вещей. Системы реального времени (стр. 4. Springer.)

16. Кумар Дас, С., Шарма, Г., и Кумар Кевт, П .: Целостность и аутентификация с использованием криптографии с эллиптической кривой

. Журнал междисциплинарных исследований Imperial.

17. Lechelt, Z., Rogers, Y., Marquardt, N., & Shum, V .: Connectus: A New Toolkit

for Teaching about the Internet of Things. Материалы конференции CHI 2016

по расширенным тезисам о человеческом факторе в вычислительных системах (стр. 4, Нью-Йорк:

ACM)

18. Мэйтин-Шепард, Дж., Тибучи, М., и Аранья, Д .: Хеширование мультимножества эллиптических кривых.

Криптография и безопасность.

19. Малина, Л., Хайны, Дж., И Хосек, Дж .: О перспективах безопасности и конфиденциальности —

Сохранение решений в Интернете вещей.Компьютерные сети, 83-95.

20. Назим, М. Али Шах, М., и Камран Аббаси, М .: Анализ встроенных веб-страниц в Интернете вещей. Труды Международной конференции по связи IOARP и сетям. Лондон: IOARP.

21. Нур-уль-Айн, В., Атта-ур-Рахман, М., Надим, М., и Аббаси Гафур, А .: Quan-

Tum Тенденции криптографии: веха в информационной безопасности. In Advances in

Интеллектуальные системы и вычисления (стр.4. Швейцария: Springer).

22. Пауэлл, А .: Взлом в общественных интересах: авторитет, законность, средства и цели.

Новые СМИ и общество.

23. Рао, М., и Рао, Б.: Уменьшение количества бумаги и обнаружение общих помех между несущими —

В отмененном многопользовательском CDMA-OFDM CFO Corrected Elliptic Curve Cryptog —

raphy With. Международный журнал прикладных инженерных исследований, 11 (8), 5880-

, 5888.

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

Конспект лекций по информатике, 258-269.

25. Шафаг, Х., Дюкенной, С. и Ху, У.: Talos: Обработка зашифрованных запросов для

Интернета вещей. Труды 13-й конференции ACM по встроенным сетевым сенсорным системам

. Нью-Йорк.

26. Sicari, S., Rizzardi, A., Miorandi, D., Cappiello, C., & Coen-Porisini, A .: безопасная

и ориентированная на качество прототипная архитектура для Интернета вещей. Информационная

Системы

, 43-55.

27. Smart, N .: Elliptic Curves. In Cryptography Made Simple (стр. 4. Лондон: Университет

, Бристоль.

28. WIND .: Безопасность в Интернете вещей: Уроки прошлого для будущего

connected. США: WIND.

29. Замбонелли, Ф .: На пути к общей методологии разработки программного обеспечения для In-

ternet вещей. Разработка программного обеспечения.

30. Палаттелла, М. Долер, М., Грико, А. и Риццо, Г.: Интернет оф Вещи эпохи 5G

: факторы влияния, архитектура и бизнес-модели.Журнал IEEE по избранным областям

в области связи (стр. 4. IEEE)

Сети большого радиуса действия и сети с низким энергопотреблением для Интернета вещей

Аннотация

LoRa — это беспроводной телекоммуникационная система, продвигаемая как инфраструктурное решение для Интернета вещей: конечные устройства используют LoRa через один беспроводной переход для связи со шлюзом (ами), подключенным к Интернету, и которые действуют как прозрачные мосты и ретранслируют сообщения между этими конечными устройствами. и центральный сетевой сервер.В этом документе представлен обзор LoRa и подробный анализ его функциональных компонентов. Производительность физического уровня и уровня канала передачи данных оценивается с помощью полевых испытаний и моделирования. На основе анализа и оценок предлагаются некоторые возможные решения для повышения производительности.

Ключевые слова: LoRa, Интернет вещей, большие расстояния, низкое энергопотребление

1. Введение

Существенное различие между «Интернетом» и «Интернетом вещей» (IoT) [1] заключается в том, что в IoT , в данном устройстве или сетевом устройстве доступно «всего меньше»: меньше памяти, меньше вычислительная мощность, меньше пропускная способность и т. д.; и, конечно же, меньше доступной энергии. Это связано либо с тем, что «вещи» питаются от батарей и максимизация срока службы является приоритетом, либо потому, что ожидается, что их количество будет огромным (по оценкам, к 2020 году будет 50 миллиардов подключенных устройств [2]). Это стремление «делать больше с меньшими затратами» приводит к ограничениям, которые ограничивают применимость традиционных сотовых сетей, а также таких технологий, как Wi-Fi, из-за требований к энергопотреблению и масштабируемости.

Появился еще один ряд протоколов и технологий, отвечающих требованиям связи Интернета вещей: маломощные глобальные сети (LPWAN).Говоря простым языком, LPWAN должен быть для IoT тем же, чем WiFi был для потребительских сетей: предлагая радиопокрытие на (очень) большой территории посредством базовых станций и адаптируя скорость передачи, мощность передачи, модуляцию, рабочие циклы и т. Д., Таким образом, конечные устройства потребляют очень мало энергии из-за их подключения.

LoRa (LoRa Alliance, https://lora-alliance.org) является одним из таких протоколов LPWAN и является предметом исследования в данной статье. LoRa нацелена на развертывания, в которых конечные устройства имеют ограниченное энергопотребление (например, с батарейным питанием), где конечным устройствам не нужно передавать более нескольких байтов за раз [3] и где трафик данных может быть инициирован либо концом -устройство (например, когда конечное устройство является датчиком) или внешним объектом, желающим связаться с конечным устройством (например, когда конечное устройство является исполнительным механизмом).Характер LoRa с большим радиусом действия и низким энергопотреблением делает его интересным кандидатом для технологии интеллектуального зондирования в гражданской инфраструктуре (например, мониторинг состояния здоровья, интеллектуальный учет, мониторинг окружающей среды и т. Д.), А также в промышленных приложениях.

1.1. Связанные работы

Были предложены и внедрены различные коммуникационные технологии, нацеленные на маломощную беспроводную связь IoT. Как указано выше, они в основном делятся на две категории:

Маломощные локальные вычислительные сети с радиусом действия менее 1000 м.В эту категорию входят IEEE 802.15.4, IEEE P802.1ah, Bluetooth / LE и т. Д., Которые применимы непосредственно в личных сетях малого радиуса действия, в локальных сетях или, если они организованы в ячеистой топологии, также на больших территориях.
Маломощные глобальные сети с радиусом действия более 1000 м, по сути, маломощные версии сотовых сетей, где каждая «ячейка» охватывает тысячи конечных устройств. В эту категорию входят LoRaWAN, а также протоколы, такие как Sigfox, DASH7 и т. Д.

В этом разделе представлена перспектива LoRaWAN, дается краткий обзор этих связанных технологий связи IoT.

1.1.1. IEEE802.15.4

IEEE 802.15.4 [4] — это стандарт, определяющий физический уровень и уровень канала данных для низкоскоростных беспроводных персональных сетей (LR-WPAN). Поддерживая три нелицензированных полосы частот (868 МГц, Европа; 928 МГц, Северная Америка; 2,4 ГГц, весь мир), IEEE 802.15.4 может предлагать скорость передачи данных до 250 кбит / с в диапазоне передачи, в значительной степени зависящем от окружающей среды; в то время как для прямой видимости возможно расстояние до 1000 м; Увы, в большинстве случаев дальность передачи измеряется десятыми долями метра.Построенный на основе физического уровня IEEE 802.15.4 и уровня канала передачи данных, ZigBee [5] предлагает профили связи, ориентированные на приложения, и сетевой уровень.

1.1.2. Bluetooth / LE

Выпущенный в 1999 году консорциумом во главе с Ericsson, Nokia и Intel, Bluetooth v1.0 изначально был разработан для беспроводной замены кабелей для соединения устройств, обычно используемых вместе, таких как сотовые телефоны, ноутбуки, гарнитуры, клавиатуры и т. Д. и т. д., предлагая более низкую скорость передачи данных (скорость необработанных данных 1 Мбит / с, макс.) и относительно небольшой диапазон (теоретически, официально до 100 м, при максимальной мощности передачи, реально 5–10 м), а также низкое энергопотребление. потребление.

Несколько более поздних версий Bluetooth, Bluetooth 4.0 был завершен в 2010 году. Полностью совместимый с Bluetooth 1.0, эта версия поддерживает более высокую скорость передачи данных (скорость необработанных данных 24 Мбит / с на основе WiFi) и включает расширение «с низким энергопотреблением» (называемое Bluetooth / LE или «Smart»). По сравнению с «версией, отличной от LE», Bluetooth / LE обеспечивает функции быстрого установления соединения (более простое сопряжение) и дополнительно снижает скорость передачи данных (примерно 200 кбит / с) для снижения энергопотребления с целью запуска беспроводного датчика на не менее одного года на одну монетную ячейку (примерно 200 мАч ) [6].

1.1.3. IEEE 802.11 ah

IEEE [7,8] предоставляет стандарт беспроводной локальной сети, работающий в не требующих лицензии полосах частот ниже 1 ГГц. Работа проводится Рабочей группой IEEE 802.11 ah (TGah). По сравнению с IEEE 802.11 (работающим на частотах 2,4 ГГц и 5 ГГц) 802.11 ah поддерживает большую дальность передачи до 1 км при мощности передачи по умолчанию 200 мВт. В зависимости от назначенной полосы пропускания 802.11 ah может работать со скоростью 4 или 7,8 Мбит / с. Если состояние канала достаточно хорошее, 802.11 ah может обеспечить скорость передачи данных в сотни Мбит / с благодаря новым схемам модуляции и кодирования, заимствованным из 802.11 ак.

1.1.4. Sigfox

Sigfox (http://www.sigfox.com) — это разновидность сотовой системы, которая позволяет удаленным устройствам подключаться к точке доступа ab с помощью сверхузкой полосы частот (UNB). Запатентованная технология, разработанная и предоставленная французской компанией Sigfox, подробных общедоступных спецификаций нет. Sigfox работает в полосе частот 868 МГц, при этом спектр разделен на 400 каналов по 100 Гц [9]. Каждое оконечное устройство может отправлять до 140 сообщений в день с размером полезной нагрузки 12 октетов со скоростью передачи данных до 100 бит / с.Sigfox утверждает, что каждая точка доступа может обслуживать до миллиона оконечных устройств с зоной покрытия 30–50 км в сельской местности и 3–10 км в городах. Заявление Sigfox о том, что это технология с низким энергопотреблением, в немалой степени проистекает из того, что конечные устройства сильно загружены из-за предположения о характере шаблонов трафика данных в IoT: когда конечное устройство имеет сообщение для отправки схема интерфейса Sigfox просыпается, и сообщение передается «восходящей линии связи» с конечного устройства; затем конечное устройство в течение короткого времени прослушивает данные, отправляемые по «нисходящей линии связи» на конечное устройство.Другими словами, трафик нисходящей линии связи поддерживается активным опросом конечного устройства, что делает Sigfox интересным выбором для сбора данных, но, возможно, в меньшей степени для сценариев управления и контроля.

1.1.5. DASH7

DASH7 [10] — это протокол полного стека взаимодействия открытых систем (OSI) беспроводных датчиков и исполнительных механизмов, который работает в нелицензируемых диапазонах ISM / SRD 433 МГц, 868 МГц и 915 МГц. Это происходит из стандарта ISO 18000-7 [11] для активных RFID, разработанного U.С. Министерство обороны по инвентаризации контейнеров. DASH7 наследует от ISO / IEC 18000-7 параметры по умолчанию для активного радиоинтерфейса на частоте 433 МГц, асинхронного MAC и уровня представления с использованием высокоструктурированных элементов данных. Кроме того, DASH7 расширяет и определяет стек протоколов от физического уровня до уровня приложений.

DASH7 нацелен на обеспечение связи в диапазоне до 2 км, малую задержку, поддержку мобильности, многоуровневое время автономной работы, поддержку 128-битного шифрования с общим ключом AES и скорость передачи данных до 167 кбит / с.

В [12] представлен более подробный обзор различных технологий, включая 3GPP LTE Rel-13, узкополосный LTE-M от Nokia, узкополосное предложение Neul / Huawei, Sigfox и т. Д.

1.2. Заявление о цели

В литературе было несколько статей, связанных с LoRa. В [13,14] сравниваются различные технологии дальнего действия, в том числе LoRa. Petajajarvi et al. [15] изучили покрытие LoRa и предложили модель затухания в канале. В [16] авторы проанализировали пропускную способность LoRa и предложили LoRaBlink для поддержки многозвенной связи.

Дополняя работу этих статей, данная статья преследует три цели: (i) учитывая полуприетарный характер LoRA (части протокола хорошо документированы, другие части — нет), предоставить обзор и функциональное описание LoRa и предоставить как можно больше информации (экспериментально или иным образом), собранной; (ii) для независимой количественной оценки и оценки производительности LoRA и LoRaWAN, особенно фактора распространения; и (iii) на основе анализа и оценки производительности предложить возможные решения для повышения производительности.

Остальная часть этого документа организована следующим образом: Раздел 2 представляет функциональный обзор LoRa, за которым следует Раздел 3, в котором подробно описывается и анализируется физический уровень LoRa и приводятся экспериментальные исследования производительности. Далее протокол MAC LoRaWAN описывается в разделе 4, а в разделе 5 представлена его оценка для LoRaWAN. Раздел 6 завершает эту статью.

2. Обзор LoRa

В этом разделе дается обзор стека протоколов LoRa и базовой сетевой архитектуры.

2.1. Стек протоколов LoRa

LoRa, что означает «Long Range», представляет собой систему беспроводной связи большого радиуса действия, продвигаемую LoRa Alliance. Эта система предназначена для использования в долговечных устройствах с батарейным питанием, где потребление энергии имеет первостепенное значение. LoRa обычно может относиться к двум различным уровням: (i) физический уровень, использующий метод радиомодуляции Chirp Spread Spectrum (CSS) [17]; и (ii) протокол уровня MAC (LoRaWAN), хотя система связи LoRa также подразумевает особую архитектуру сети доступа.

Физический уровень LoRa, разработанный Semtech, обеспечивает связь на больших расстояниях, с низким энергопотреблением и низкой пропускной способностью. Он работает в диапазонах ISM 433, 868 или 915 МГц, в зависимости от региона, в котором он развернут. Полезная нагрузка каждой передачи может составлять от 2 до 255 октетов, а скорость передачи данных может достигать 50 Кбит / с при использовании агрегации каналов. Метод модуляции является запатентованной технологией Semtech.

LoRaWAN предоставляет механизм управления доступом к среде, позволяющий многим конечным устройствам связываться со шлюзом с использованием модуляции LoRa.Хотя модуляция LoRa является частной собственностью, LoRaWAN — это открытый стандарт, разрабатываемый LoRa Alliance.

2.2. Архитектура сети LoRa

Типичная сеть LoRa представляет собой «звездообразную топологию», которая включает три различных типа устройств, как показано на.

Сетевая архитектура LoRa.

Базовая архитектура сети LoRaWAN выглядит следующим образом: конечные устройства обмениваются данными со шлюзами, используя LoRa с LoRaWAN. Шлюзы пересылают необработанные кадры LoRaWAN с устройств на сетевой сервер через транзитный интерфейс с более высокой пропускной способностью, обычно через Ethernet или 3G.Следовательно, шлюзы являются только двунаправленными ретрансляторами или преобразователями протоколов, при этом сетевой сервер отвечает за декодирование пакетов, отправленных устройствами, и генерацию пакетов, которые должны быть отправлены обратно на устройства. Существует три класса оконечных устройств LoRa, которые различаются только планированием нисходящей линии связи.

3. Физический уровень LoRa

Модуляция LoRa является частной технологией Semtech и, как таковая, не полностью открыта. В этом разделе представлен анализ (открытых частей LoRa) и экспериментальная оценка (проприетарных частей LoRa) с целью понять, наблюдается ли на практике заявленная производительность LoRa.

3.1. Обзор физического уровня

LoRa — это модуляция с расширенным спектром ЛЧМ [18], которая использует частотные ЛЧМ-сигналы с линейным изменением частоты во времени для кодирования информации. Из-за линейности импульсов ЛЧМ сдвиги частоты между приемником и передатчиком эквивалентны сдвигам синхронизации, которые легко устраняются в декодере. Это также делает эту модуляцию невосприимчивой к эффекту Доплера, эквивалентному смещению частоты. Сдвиг частоты между передатчиком и приемником может достигать 20% ширины полосы без снижения производительности декодирования [19].Это помогает снизить стоимость передатчиков LoRa, поскольку кристаллы, встроенные в передатчики, не нужно производить с высокой точностью. Приемники LoRa могут захватывать принимаемые частотные чирпы, предлагая чувствительность порядка -130 дБм [19,20].

Поскольку длительность символа LoRa больше, чем типичные пакеты AM-помех, генерируемых системами с расширенным спектром со скачкообразной перестройкой частоты (FHSS), ошибки, вызванные такими помехами, легко исправляются с помощью кодов прямой коррекции ошибок (FEC).Типичная внеканальная избирательность (максимальное соотношение мощности между источником помех в соседнем диапазоне и сигналом LoRa) и подавление совмещенного канала (максимальное соотношение мощности между источником помех в том же канале и сигналом LoRa) Приемники LoRa составляют соответственно 90 дБ и 20 дБ [19,20]. Это превосходит традиционные схемы модуляции, такие как частотная манипуляция (FSK), и делает LoRa хорошо подходящим для маломощных передач и передач на большие расстояния.

3.2. Параметры физического уровня

Для настройки модуляции LoRa доступны несколько параметров: полоса пропускания ( B W ), коэффициент расширения ( S F ) и кодовая скорость ( C R ) .LoRa использует нетрадиционное определение коэффициента расширения как логарифма по основанию 2 числа щебетаний на символ. Для простоты в этой статье мы будем придерживаться этого определения. Эти параметры влияют на эффективный битрейт модуляции, ее устойчивость к помехам и простоту декодирования.

Ширина полосы — самый важный параметр модуляции LoRa. Символ LoRa состоит из 2 ^{S F} щебетаний, которые охватывают всю полосу частот.Он начинается с серии восходящих щебетаний. Когда достигается максимальная частота полосы, частота меняется, и увеличение частоты начинается снова с минимальной частоты. дает пример передачи LoRa в изменении частоты во времени. Положение этого разрыва частоты — это то, что кодирует передаваемую информацию. Поскольку в символе есть 2 ^{S F} щебетаний, символ может эффективно кодировать S F бита информации.

Изменение частоты во времени образца сигнала, излучаемого передатчиком LoRa. Данные взяты из [21]. f _c — центральная частота канала, а B W — ширина полосы.

В LoRa частота щебета зависит только от полосы пропускания: скорость щебета равна ширине полосы (один щебетание в секунду на герц полосы пропускания). Это имеет несколько последствий для модуляции: увеличение одного из коэффициентов расширения разделит полосу частот ЛЧМ на два (поскольку 2 ^{S F} ЛЧМ покрывают всю полосу частот) и умножит длительность символа. на два тоже.Однако он не будет делить битрейт на два, так как в каждом символе будет передаваться еще один бит. Более того, символьная скорость и битовая скорость при заданном коэффициенте расширения пропорциональны ширине полосы частот, поэтому удвоение полосы пропускания фактически удвоит скорость передачи. Это транслируется в уравнении (1), которое связывает длительность символа ( T _S) с полосой пропускания и коэффициентом расширения.

Кроме того, LoRa включает код прямого исправления ошибок.Кодовая скорость ( C R ) равна 4 / (4 + n ), причем n ∈ {1, 2, 3, 4}. Принимая во внимание это, а также тот факт, что S F бит информации передается на символ, уравнение (2) позволяет вычислить полезную скорость передачи битов ( R _b).

Например, установка с B W = 125 кГц, S F = 7, C R = 4/5 дает битрейт R _b = 5.5 кбит / с.

Эти параметры также влияют на чувствительность декодера. Вообще говоря, увеличение полосы пропускания снижает чувствительность приемника, тогда как увеличение коэффициента расширения увеличивает чувствительность приемника. Уменьшение кодовой скорости помогает снизить частоту ошибок пакета (PER) при наличии коротких пакетов помех, т. Е. Пакет, передаваемый с кодовой скоростью 4/8, будет более устойчив к помехам, чем сигнал, передаваемый с кодовой скоростью 4/5. Цифры, взятые из таблицы данных SX1276, даны для справки.

Таблица 1

Semtech SX1276 Чувствительность приемника LoRa в дБм при различных полосах пропускания и коэффициентах расширения, взято из [19].

9048 125 483 9048 12 485 9048 9048 кГц

	SF	7	8	9	10	11	12
BW		7	8	9	10	11	12
−129	−132	−133	−136
250 кГц		−120	−123	−125	−128	−130

−116	−119	−122	−125	−128	−130

Еще одним параметром модуляции LoRa, который реализован в трансиверах Semtech, является низкая скорость передачи данных. .Этот параметр является обязательным в LoRa при использовании коэффициентов расширения 11 и 12 с полосой пропускания 125 кГц или ниже. Действие этого параметра не задокументировано; однако уравнение (3) показывает, что оно уменьшает количество битов, передаваемых на символ, на два.

3.3. Физический формат кадра

Хотя модуляция LoRa может использоваться для передачи произвольных кадров, физический формат кадра определен и реализован в передатчиках и приемниках Semtech. Ширина полосы пропускания и коэффициент расширения для кадра постоянны.

Кадр LoRa начинается с преамбулы. Преамбула начинается с последовательности постоянных повышающих частот, которые покрывают всю полосу частот. Последние два модуля upchirp кодируют синхрослово. Синхронизирующее слово — это однобайтовое значение, которое используется для различения сетей LoRa, использующих одни и те же полосы частот. Устройство, сконфигурированное с данным словом синхронизации, прекратит прослушивание передачи, если декодированное слово синхронизации не соответствует его конфигурации. За словом синхронизации следуют два с четвертью нисходящих сигналов длительностью 2.25 символов. Общая продолжительность этой преамбулы может быть настроена от 10,25 до 65 539,25 символов. Структуру преамбулы можно увидеть в.

После преамбулы идет необязательный заголовок. Когда он присутствует, этот заголовок передается с кодовой скоростью 4/8. Это указывает размер полезной нагрузки (в байтах), кодовую скорость, используемую для конца передачи, и наличие или отсутствие 16-битного CRC для полезной нагрузки в конце кадра. Заголовок также включает CRC, чтобы приемник мог отбрасывать пакеты с недопустимыми заголовками.Размер полезной нагрузки хранится в одном байте, ограничивая размер полезной нагрузки 255 байтами. Заголовок является необязательным, чтобы можно было отключить его в ситуациях, когда в этом нет необходимости, например, когда длина полезной нагрузки, скорость кодирования и наличие CRC известны заранее.

Полезная нагрузка отправляется после заголовка, а в конце кадра — необязательный CRC. Схематическое изображение формата кадра можно увидеть на.

Структура кадра LoRa. n ∈ {1..4}.

Уравнение (3), полученное из таблиц данных Semtech [19,20], дает количество символов, необходимых для передачи полезной нагрузки n _s, как функцию всех этих параметров.Это число следует добавить к количеству символов преамбулы, чтобы вычислить общий размер пакета в символах. В этом уравнении P L — размер полезной нагрузки в байтах, C R C — 16, если CRC включен, и ноль в противном случае, H — 20, когда заголовок включен, и ноль в противном случае. и D E равно двум, когда включена оптимизация с низкой скоростью передачи данных, и нулю в противном случае. Это уравнение также показывает, что минимальный размер пакета составляет восемь символов.

нс = 8 + max8PL − 4SF + 8 + CRC + h5 × (SF − DE) × 4CR, 0

(3)

3.4. Оценка производительности

Чтобы проверить, достигаются ли заданные характеристики приемников LoRa на практике, создается испытательный стенд LoRa. Плата для разработки Freescale KRDM-KL25Z с экраном Semtech SX1276 MBED (a) используется в качестве конечного устройства, а промышленный маршрутизатор Cisco 910 используется в качестве шлюза (b). Шлюз подключен к сетевому серверу, предоставленному Thingpark (https: //actility.thingpark.com) через Ethernet, чтобы полученный пакет можно было отслеживать на стороне сервера.

Стенд LoRa. ( a ) Конечное устройство LoRa; ( b ) шлюз LoRa.

3.4.1. Чувствительность приемника

Поскольку существует множество моделей и оценок распространения радиосигналов на частотах, используемых LoRa в различных средах [22], этот эксперимент сосредоточен на проверке характеристик декодирования приемников LoRa.

С этой целью с устройства LoRa на шлюз было отправлено около 10 000 пакетов, а индикаторы уровня принятого сигнала (RSSI) полученных пакетов были записаны при перемещении конечного устройства.Шлюз размещался в помещении, а устройство — на улице, в городской среде. Все пакеты были отправлены с полосой пропускания 125 кГц и кодовой скоростью 4/5. Мощность передачи устройства была установлена на минимум (2 дБмВт, с антенной 3 дБи), чтобы ограничить расстояние, которое необходимо покрыть до достижения низких значений RSSI. Порядок величины расстояния между оконечным устройством и шлюзом, на котором начали теряться пакеты, составлял 100 м. Минимальные наблюдаемые RSSI показаны в.

Минимальные наблюдаемые RSSI с разными коэффициентами распространения.

Эти результаты измерений немного превышают указанные значения, и ожидаемого уменьшения с увеличением коэффициента расширения не наблюдается. Однако пакеты, достигающие самых низких значений RSSI, также были получены с высоким SINR, близким к 20 дБ. Вероятно, это связано с тем, что шлюз находится в помещении, что приводит к дополнительному затемнению.

Следует отметить, что наблюдаемые RSSI уже на 6 дБ ниже указанных RSSI при использовании FSK [19].

3.4.2. Покрытие сети

Этот эксперимент направлен на тестирование покрытия сети LoRa.Испытания проводились в пригороде Парижа, в основном с малоэтажными жилыми домами. Температура составляла 15 ° C, а влажность окружающей среды составляла 55%. Шлюз находился на втором этаже дома, за окном. Было выбрано пять различных контрольных точек с расстоянием до шлюза, как показано на. Конечное устройство во время испытаний находилось в автомобиле.

Мощность передачи оконечного устройства была установлена на 14 дБм, что является значением по умолчанию, как указано в [23]. Чтобы проверить производительность различных факторов расширения, подтверждение и повторная передача пакетов были отключены.Также была отключена проверка канала, чтобы коэффициент расширения не изменился даже в случае потери пакетов; по умолчанию LoRa адаптирует коэффициент распространения в соответствии с качеством связи. Для испытаний были выбраны коэффициенты распространения 7, 9 и 12.

показывает коэффициент доставки пакетов с разными коэффициентами расширения на разных расстояниях. В каждом тесте на сетевой сервер передается около 100 пакетов с порядковым номером. Чем выше коэффициент распространения, тем лучше охват, как описано в разделе 3.2: для коэффициента расширения 12 более 80% пакетов были получены в точке D (2800 м), в то время как при использовании коэффициента расширения семи пакетов не было получено ни одного пакета. Стоит отметить, что шлюз располагался на втором этаже, который находился примерно в 5 м над землей (обычно такая базовая станция должна располагаться на большей высоте для достижения лучшего покрытия), а контрольная точка D находилась сразу за ней. здание семи этажей. Высокая степень доставки с использованием высокого коэффициента расширения имеет цену гораздо более низкой скорости передачи данных, как показано в уравнении (2).С другой стороны, покрытие сети с низкими коэффициентами распространения намного меньше.

Коэффициент доставки пакетов при полевом тесте LoRa.

Важно отметить, что целью приведенных выше тестов является проверка покрытия физического уровня LoRa с использованием различных коэффициентов расширения. В реальной сети LoRa с протоколом LoRaWAN конечные устройства могут автоматически увеличивать коэффициент расширения, если передача с более низким коэффициентом расширения не удалась. Кроме того, при необходимости используется ретрансляция.Следовательно, в сети с LoRaWAN может быть достигнута более высокая степень доставки.

4. Протокол LoRaWAN

LoRaWAN — это протокол MAC, созданный для использования физического уровня LoRa. Он разработан в основном для сенсорных сетей, в которых датчики обмениваются пакетами с сервером с низкой скоростью передачи данных и относительно длинными интервалами времени (одна передача в час или даже дни). В этом разделе описывается спецификация LoRaWAN V1.0 [23], выпущенная в январе 2015 года.

4.1. Компоненты сети LoRaWAN

Некоторые компоненты сети определены в спецификации LoRaWAN и необходимы для формирования сети LoRaWAN: конечные устройства, шлюзы (т.е., базовые станции) и сетевой сервер.

Конечное устройство: датчики с низким энергопотреблением, которые обмениваются данными со шлюзами с помощью LoRa.
Шлюз: промежуточные устройства, которые пересылают пакеты, поступающие от конечных устройств, на сетевой сервер через интерфейс обратного IP-соединения, обеспечивающий большую пропускную способность, например Ethernet или 3G. В развертывании LoRa может быть несколько шлюзов, и один и тот же пакет данных может быть получен (и перенаправлен) более чем одним шлюзом.
Сетевой сервер: отвечает за дедупликацию и декодирование пакетов, отправленных устройствами, и генерацию пакетов, которые должны быть отправлены обратно на устройства.

В отличие от традиционных сотовых сетей, конечные устройства не связаны с конкретным шлюзом, чтобы иметь доступ к сети. Шлюзы служат просто как ретранслятор канального уровня и пересылают пакет, полученный от оконечных устройств, на сетевой сервер после добавления информации о качестве приема.Таким образом, конечное устройство связано с сетевым сервером, который отвечает за обнаружение повторяющихся пакетов, выбор соответствующего шлюза для отправки ответа (если таковой имеется), следовательно, для отправки пакетов обратно на конечные устройства. По логике, шлюзы прозрачны для конечных устройств.

LoRaWAN имеет три разных класса оконечных устройств для удовлетворения различных потребностей приложений:

Класс A, двунаправленный: Конечные устройства класса A могут планировать передачу по восходящей линии связи на основе своих собственных потребностей с небольшим дрожанием (случайное изменение перед передачей).Этот класс устройств обеспечивает двунаправленную связь, при которой каждая передача по восходящей линии связи сопровождается двумя короткими окнами приема по нисходящей линии связи. Передача по нисходящему каналу от сервера в любое другое время должна ждать, пока не произойдет следующая передача по восходящему каналу. Устройства класса A имеют самое низкое энергопотребление, но также предлагают меньшую гибкость при передаче по нисходящей линии связи.
Класс B, двунаправленный с запланированными слотами приема: оконечные устройства класса B открывают дополнительные окна приема в запланированное время.Таким образом, требуется синхронизированный маяк от шлюза, чтобы сетевой сервер мог знать, когда конечное устройство прослушивает.
Класс C, двунаправленный с максимальным количеством слотов приема: оконечные устройства класса C имеют почти непрерывные окна приема. Таким образом, они имеют максимальное энергопотребление.

Следует отметить, что LoRaWAN не поддерживает обмен данными между устройствами: пакеты могут передаваться только с конечного устройства на сетевой сервер или наоборот.Таким образом, обмен данными между устройствами, если это необходимо, должен осуществляться через сетевой сервер (и, следовательно, посредством передачи данных через два шлюза).

В спецификации LoRaWAN указано, что сети LoRaWAN должны использовать полосы частот ISM. Эти диапазоны регулируются правилами, касающимися максимальной мощности передачи и рабочего цикла. Эти ограничения рабочего цикла приводят к задержкам между последовательными кадрами, отправляемыми устройством. Если ограничение составляет 1%, устройству придется ждать в 100 раз больше продолжительности последнего кадра перед повторной отправкой по тому же каналу.

4.2. Формат сообщения LoRaWAN

LoRaWAN использует формат физического кадра, описанный в разделе 3.3. Заголовок и CRC являются обязательными для сообщений восходящей линии связи, что делает невозможным использование коэффициента расширения шесть в LoRaWAN. Сообщения нисходящего канала имеют заголовок, но не CRC. Кодовая скорость, которую следует использовать, не указана, как и когда оконечные устройства должны использовать оптимизацию с низкой скоростью передачи данных.

Формат сообщения подробно описан в. DevAddr — это короткий адрес устройства. FPort — это поле порта мультиплексирования. Нулевое значение означает, что полезная нагрузка содержит только команды MAC. В этом случае поле FOptsLen должно быть нулевым. FCnt — счетчик кадров. MIC — это криптографический код целостности сообщения, вычисляемый по полям MHDR , FHDR , FPort и зашифрованной FRMPayload . MType — это тип сообщения, указывающий, среди прочего, является ли это сообщением восходящей или нисходящей линии связи, и является ли это подтвержденным сообщением.Подтверждения требуются для подтвержденных сообщений. Major — версия LoRaWAN; в настоящее время допустимо только нулевое значение. ADR и ADRAckReq управляют механизмом адаптации скорости передачи данных сетевым сервером. ACK подтверждает последний полученный кадр. FPending указывает, что у сетевого сервера есть дополнительные данные для отправки и что конечное устройство должно как можно скорее отправить другой кадр, чтобы оно открывало окна приема. FOptsLen — это длина поля FOpts в байтах. FOpts используется для совмещения MAC-команд с сообщением данных. CID — это идентификатор команды MAC, а Args — это необязательные аргументы команды. FRMPayload — это полезная нагрузка, которая зашифрована с использованием AES с длиной ключа 128 бит. Минимальный размер заголовка MAC составляет 13 байтов; его максимальный размер — 28 байт. Зная это, можно вычислить максимальную пропускную способность канала, доступную для полезных данных приложения с заданными параметрами модуляции, благодаря уравнениям (1) и (3).Поскольку пакеты отправляются с устройства на сетевой сервер и наоборот, в пакетах восходящей линии связи нет адреса назначения, а в пакетах нисходящей линии связи нет адреса источника.

Формат кадра LoRaWAN. Размеры полей указаны в битах.

4.3. Настройка конечного устройства

Чтобы участвовать в сети LoRaWAN, конечное устройство должно быть активировано. LoRaWAN предоставляет два способа активации конечного устройства: активация по беспроводной сети (OTAA) и активация с помощью персонализации (ABP).

Процесс активации должен предоставить конечному устройству следующую информацию:

Адрес конечного устройства ( DevAddr ): 32-битный идентификатор конечного устройства.Семь бит используются в качестве идентификатора сети, а 25 бит используются в качестве сетевого адреса конечного устройства.
Идентификатор приложения ( AppEUI ): глобальный идентификатор приложения в адресном пространстве IEEE EUI64, который однозначно идентифицирует владельца конечного устройства.
Сетевой сеансовый ключ ( NwkSKey ): ключ, используемый сетевым сервером и конечным устройством для расчета и проверки кода целостности всех сообщений данных для обеспечения целостности данных.
Ключ сеанса приложения ( AppSKey ): ключ, используемый сетевым сервером и конечным устройством для шифрования и дешифрования поля полезной нагрузки сообщений данных.

Для OTAA процедура присоединения с запросом на присоединение и обмен сообщениями о присоединении используется для каждого нового сеанса. На основе сообщения о присоединении-приеме конечные устройства могут получить новые сеансовые ключи ( NwkSkey и AppSKey ). Для ABP два сеансовых ключа хранятся непосредственно в конечных устройствах.

4.4. Команды MAC LoRaWAN

LoRaWAN определяет множество команд MAC, которые позволяют настраивать параметры конечного устройства [23]. Один из них, LinkCheckReq , может быть отправлен конечным устройством для проверки его возможности подключения. Все остальные отправляются сетевым сервером. Эти команды могут управлять скоростью передачи данных и выходной мощностью, используемыми устройством, а также количеством раз, когда каждый неподтвержденный пакет должен быть отправлен ( LinkADRReq ), общим рабочим циклом устройства ( DutyCycleReq ), изменением параметров окна приема ( RXTimingSetupReq , RXParamSetupReq ) и изменение каналов, используемых устройством ( NewChannelReq ).Одна команда используется для запроса уровня заряда батареи и качества приема устройства ( DevStatusReq ).

5. Анализ LoRaWAN

В этом разделе анализируется и обсуждается производительность LoRaWAN посредством экспериментов и моделирования. Как и в предыдущем разделе, все это исследование основано на [23].

5.1. Максимальная пропускная способность одного устройства и MTU

Цель этого эксперимента — оценить максимальную пропускную способность, которую может получить одно устройство. Это больше зависит от физического уровня, чем от протокола MAC, но дает представление о том, что возможно при использовании LoRaWAN.Эксперимент проводился с устройством, отправляющим данные, как только ограничения канала и протокол позволяют это. Испытания проводились с шестью каналами по 125 кГц и с коэффициентами расширения от 7 до 12. Команды MAC не отправлялись, поэтому размер заголовка MAC всегда составлял 13 байтов. Результаты, в зависимости от размера полезной нагрузки, видны в, которые измеряются примерно для 100 пакетов, переданных в каждом тесте. Пятьдесят один байт — это максимальный размер полезной нагрузки, разрешенный реализацией, используемой для тестов.

Максимальная пропускная способность, достигаемая одним устройством с использованием LoRaWAN.

Этот эксперимент показал, что при малых размерах пакетов ограничивающим фактором были не ограничения рабочего цикла канала, как можно было ожидать, а продолжительность окон приема. Действительно, устройство должно дождаться завершения двух окон приема нисходящей линии связи, следующих за передачей, перед отправкой другого пакета. Однако эта ситуация не является тем вариантом использования, для которого был разработан LoRaWAN: цель LoRaWAN, скорее, состоит в том, чтобы управлять большим количеством устройств, которые время от времени отправляют несколько байтов данных.

В приведенных выше тестах заголовок MAC всегда равен 13 байтам. Однако на практике заголовок LoRaWAN может иметь переменный размер от 13 до 28 байтов. Более того, максимальный размер кадра зависит от используемой скорости передачи данных [23], а LoRaWAN не имеет механизма для разделения больших данных на несколько кадров. Что касается текущей спецификации, приложение выше LoRaWAN не имеет возможности узнать, каков максимальный размер пакета, который он сможет отправить при следующей передаче, что может быть проблематичным.Консервативный подход состоит в том, чтобы никогда не пытаться отправить больше, чем наименьший максимальный размер полезной нагрузки, который составляет 36 байтов, но это приводит к потере емкости, если необходимо отправить большой объем данных, а также к более низкой пропускной способности, как показано на результаты в. Это относительно легко решить в будущей версии спецификации LoRaWAN, либо добавив механизм фрагментации, либо сообщив верхнему уровню MTU из протокола MAC.

5.2. Общая емкость и нагрузка на канал

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

Общая пропускная способность сети LoRaWAN — это сумма пропускных способностей всех логических каналов. В полосе частот 125 кГц существует шесть возможных коэффициентов расширения (от 7 до 12), что увеличивает общую пропускную способность канала 125 кГц до 12 025 бит / с.

В полосе частот ЕС набор обязательных каналов содержит три канала 125 кГц [23], что составляет минимальную общую пропускную способность сети 36 кбит / с.Операторы сети могут добавлять дополнительные каналы (отправленные на устройства с помощью команд NewChannelReq ), тем самым увеличивая пропускную способность сети.

Поскольку скорость передачи битов зависит от коэффициента расширения, не все логические каналы имеют одинаковую пропускную способность. В дальнейшем нагрузка для логического канала определяется средним по времени количеством устройств LoRa, пытающихся отправить данные. Это совпадает с естественным определением нагрузки: в оптимальных условиях, т.е.Т.е. при идеальной синхронизации устройств может быть достигнута нагрузка в единицу, насыщая канал.

5.3. Оценка частоты конфликтов

Согласно текущей спецификации, устройства и шлюзы могут передавать данные в любое время. Нет никакого механизма «слушай перед разговором» или механизма CSMA. Это делает LoRaWAN очень похожим на ALOHA [24], но в отличие от ALOHA с переменной длиной пакета.

Из-за юридических ограничений рабочего цикла в 1% в регионе ЕС, где проводился этот анализ, потребовалось бы 100 устройств для эмуляции нагрузки одного, и это число увеличилось бы пропорционально максимальной нагрузке на канал, которую мы хотели. тестировать.Поскольку под рукой было не так много устройств, для оценки поведения LoRaWAN под нагрузкой используются симуляции.

Имитатор был построен для моделирования случайного процесса пакетной эмиссии. Для каждой точки данных моделировалось пятьсот тысяч пакетов. Если время передачи двух пакетов перекрывается, мы считаем, что происходит коллизия и ни один из двух пакетов не достигает шлюза. Частота конфликтов — это количество столкнувшихся пакетов, деленное на общее количество пакетов, отправленных во время моделирования.Использование пропускной способности канала вычисляется как количество данных, успешно переданных во время моделирования, деленное на теоретический максимальный объем данных, который мог быть отправлен в канале, который представляет собой пропускную способность канала, умноженную на продолжительность моделирования. Загрузка канала определяется в предыдущем разделе 5.2 или, что эквивалентно, суммой длительности всех пакетов, отправленных во время моделирования, деленной на продолжительность моделирования.

Продолжительность пакетов для различных размеров полезной нагрузки была вычислена с помощью калькулятора LoRa компании Semtech для коэффициента расширения семь, полосы пропускания 125 кГц, кодовой скорости 5/4 и шести символов в преамбуле.

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

Использование пропускной способности канала и частота конфликтов пакетов для сети LoRaWAN по сравнению с сетью ALOHA. Нагрузка определена в разделе 5.2.

Переменная длина пакета не сильно влияет на производительность LoRaWAN, и все сказано и сделано, наблюдаемое поведение очень близко к поведению чистого ALOHA.Максимальное использование емкости составляет 18% от емкости канала и достигается при нагрузке канала 0,48. Однако при этой нагрузке около 60% передаваемых пакетов отбрасываются из-за коллизий.

Это может быть проблемой, потому что, если устройства не используют подтвержденные сообщения, некоторые сообщения будут потеряны (и увеличение количества раз, когда каждое сообщение отправляется устройствами, является плохим решением, так как это увеличит нагрузку на link), и если устройства используют подтвержденные сообщения, им придется повторно передать большинство пакетов несколько раз, что, кроме того, повлияет на время автономной работы устройств.

Подтвержденные сообщения LoRaWAN, отправленные устройствами, должны быть подтверждены пакетом, отправленным в течение одного из двух окон приема после передачи, в то время как подтвержденные сообщения, отправленные шлюзом, будут подтверждены во время следующей передачи по восходящей линии связи. Подтверждение — это только флаг в заголовке пакета, и установка этого флага подтверждает получение последнего сообщения. Таким образом, при использовании подтвержденных сообщений новый пакет не следует отправлять до получения подтверждения предыдущего пакета; в противном случае будет невозможно узнать, к какому пакету будет относиться следующее подтверждение.

Недостатком этого механизма является то, что подтвержденное сообщение требует двух последовательных передач, чтобы быть успешным, что увеличивает вероятность коллизии с другими сообщениями и количество необходимых повторных передач. Как и выше, вероятность успеха и использование пропускной способности канала, когда конечные устройства отправляют подтвержденные сообщения, могут быть нанесены на график. Для этого моделирования мы считаем, что шлюз не отправляет MAC-команды устройству, поэтому сообщение подтверждения всегда использует 13-байтовый MAC-заголовок и не использует полезную нагрузку.Мы также принимаем эти сообщения во внимание при вычислении нагрузки, то есть, когда сумма длительностей всех сообщений и их подтверждений равна продолжительности моделирования, значение нагрузки равно единице. Результат показан в.

Использование пропускной способности канала и частота конфликтов пакетов для сети LoRaWAN при использовании подтвержденных сообщений. Нагрузка определена в разделе 5.2.

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

Результаты показывают, что LoRaWAN чрезвычайно чувствителен к загрузке канала, как и ALOHA. Решение, реализованное с помощью обычных сетевых протоколов, таких как 802.11 или сотовые сети, чтобы помочь смягчить эту проблему, — это CSMA [25]. Чтобы обеспечить масштабируемость LoRaWAN, было бы интересно изучить возможность реализации механизма CSMA в LoRaWAN.Возможная проблема заключается в ограничении рабочего цикла, которое применяется к шлюзу и не позволяет ему слишком часто отправлять сообщения; другим является потенциальная нетранзитивность канала (то есть конечное устройство может или не может иметь возможность «распознавать несущую», если другое конечное устройство передает на тот же шлюз). Если текущая архитектура сохранится, механизм CSMA должен будет контролироваться сетевым сервером, что приведет к еще большей нагрузке на него. Увы, механизм CSMA также может устранить риск конфликта подтверждений для подтвержденных сообщений, сделав это в течение периода без конкуренции.

Текущая спецификация LoRaWAN не имеет никаких средств для обеспечения качества обслуживания, и, следовательно, ее не следует использовать для критически важных приложений или приложений, где задержка между первой попыткой устройства отправить сообщение и временем в которое получено, важно. Регулировка количества раз, когда устройство отправляет свои пакеты, может увеличить вероятность прохождения этих пакетов, но это происходит за счет большего количества конфликтов с передачами от других узлов и не дает никаких жестких гарантий.

LoRaWAN в настоящее время использует диапазоны ISM, которые имеют то преимущество, что они бесплатны и не требуют лицензии. Однако эти диапазоны все больше и больше используются конкурентами LoRaWAN. Даже если LoRa очень устойчив к помехам, эти полосы имеют конечную пропускную способность, и не гарантируется, что пропускная способность этой полосы будет достаточной. Более того, злоумышленник совершенно законно может испускать случайные символы LoRa, которые будут препятствовать передаче LoRa. Использование проприетарной полосы частот имело бы преимущество в устранении большинства помех, а также в снятии ограничения рабочего цикла, что, возможно, упростило бы реализацию механизма CSMA.

5.4. Роль сетевого сервера

LoRaWAN определяет поведение устройств, но не поведение сетевого сервера. Как показано в Разделе 5.3, важно поддерживать низкую нагрузку на сеть, и сетевой сервер должен обеспечивать это, отправляя MAC-команды устройствам. Однако, поскольку это не является частью спецификации и отсутствует эталонная реализация с открытым исходным кодом (на момент написания этой статьи), правильное поведение сетевого сервера оценить трудно.

Сетевой сервер может легко снизить производительность сети. Например, он может использовать команду LinkADRReq , чтобы настроить, сколько раз устройство будет отправлять каждый фрейм данных. Этот параметр рекламируется как способ управления качеством обслуживания устройства. Установка для этого параметра значения более одного увеличит нагрузку на сеть, увеличивая количество коллизий, и, таким образом, это следует делать очень осторожно.

Кроме того, рекламируется, что сети LoRaWAN могут обслуживать миллионы устройств.Сетевой сервер будет отвечать за оптимизацию всех этих узлов. Даже если частота событий в сенсорных сетях значительно ниже, чем в традиционных сетях, операторы сети должны тщательно оценить производительность сетевого сервера, чтобы обеспечить масштабирование сети.

5.5. Роль шлюза

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

Единственная задача, которую должны выполнять шлюзы, — это синхронизация сообщений нисходящей линии связи. Это время должно быть точным, чтобы устройство получило сообщение в своем окне приема. Не указано, получают ли шлюзы сообщение для отправки с сервера вместе со временем, в которое оно должно быть отправлено, или если шлюз отправляет сообщение, полученное от сервера, как только он его получает, и неясно, какое решение реализовано в существующих шлюзах.Поскольку время приема-передачи транзитного интерфейса шлюзов невозможно контролировать, следует реализовать первое решение. Это также позволило бы синхронизировать передачи различных шлюзов, избегая конфликтов между ними.

В текущей спецификации каждый шлюз выделен для определенного сетевого сервера, как показано в. Это означает, что и шлюзы, и собранные данные «принадлежат» объекту, на котором работает единственный сетевой сервер. В будущем было бы интересно расширить функции шлюзов, чтобы они могли пересылать пакет на определенные сетевые серверы, как показано на.Это может эффективно снизить расходы на устройства и развертывание сети.

Пример общих шлюзов в LoRa. Шлюзы могут пересылать пакет на разные сетевые серверы.

6. Выводы

LoRa — это маломощные телекоммуникационные системы дальнего действия для «Интернета вещей». На физическом уровне используется модуляция LoRa, запатентованная технология с протоколом MAC. LoRaWAN — это открытый стандарт, спецификация которого доступна бесплатно [23].

В этой статье дается всесторонний анализ модуляции LoRa, включая скорость передачи данных, формат кадра, коэффициент расширения, чувствительность приемника и т. Д.Был построен стенд для экспериментального изучения производительности сети, описанной в этой статье. Результаты показывают, что модуляция LoRa, благодаря модуляции с расширенным спектром ЛЧМ и высокой чувствительности приемника, обеспечивает хорошую устойчивость к помехам. Полевые испытания показывают, что LoRa может обеспечить удовлетворительное покрытие сети до 3 км в пригородной зоне с плотной жилой застройкой. Фактор расширения оказывает значительное влияние на покрытие сети, как и скорость передачи данных. Таким образом, LoRa хорошо подходит для сетей с низким энергопотреблением и пропускной способностью, а также для сетей большой дальности.

В этой статье также показано, что LoRaWAN — это протокол LPWAN, очень похожий на ALOHA. Таким образом, его производительность быстро снижается при увеличении нагрузки на канал.

[PDF] Защищенная схема единого входа в распределенных системах и сетях

Скачать схему надежно защищенного единого входа в распределенных системах и сетях …

2012 IEEE 11-я Международная конференция по доверию, безопасности и конфиденциальности в вычислениях и коммуникациях

Схема надежно защищенной единой регистрации в распределенных системах и сетях Цзяншань Юй, Гуйлинь Ван и Йи Му Центр компьютерной и информационной безопасности, Исследовательская школа компьютерных наук и программного обеспечения Инженерный университет Вуллонгонга, Австралия. Электронная почта: {jy898, guilin, ymu} @uow.edu.au, и как сохранить надежность и конфиденциальность учетных данных все еще остается проблемой [6]. В 2000 году Ли и Чанг [7] впервые предложили схему единого входа с анонимностью пользователя. Позже Ву и Сюй [8] указали, что схема Ли-Чана страдает от атак с маскировкой и раскрытия личности. Между тем Ян и др. [9] показали, что схема Wu-Hsu также не может сохранить конфиденциальность учетных данных, поскольку злонамеренный поставщик услуг может восстановить учетные данные пользователей, а затем предложил улучшение для преодоления этого ограничения.В 2006 году, однако, Мангипуди и Катти [10] указали, что схема Янга и др. Небезопасна от атак DoS (отказ в обслуживании), и представили новую схему. В 2009 г. Hsu и Chuang [11] продемонстрировали, что Yang et al. и схемы Мангипуди-Катти не обеспечивают анонимность пользователей, поскольку их схемы уязвимы для атак с раскрытием личности. Чтобы предотвратить такие атаки, Хсу и Чуанг предложили схему идентификации пользователей на основе RSA. Недавно Чанг и Ли [12] указали, что схема Hsu-Chuang уязвима для атак олицетворения, и для этой схемы требуются дополнительные синхронизированные по времени механизмы, которые имеют нестабильную задержку в распределенных сетях.Затем они предложили сохранить анонимность пользователя улучшением с высокой эффективностью. Схема использует случайный одноразовый номер для замены дополнительного механизма временной синхронизации, не требует PKI (инфраструктуры открытого ключа) для пользователей и подходит для пользователей мобильных устройств. Однако анализ безопасности [6] показывает, что схема Чанга-Ли не может обеспечить надлежащую аутентификацию пользователя и сохранить конфиденциальность учетных данных, поскольку доказательство знания аутентификации пользователя не гарантирует ни надежности, ни конфиденциальности учетных данных. Как предложено в [6], стоит преодолеть недостатки схемы Чанга-Ли, чтобы получить эффективную и доказуемо безопасную схему для пользователей мобильных устройств в распределенных системах и сетях.Более того, надежность аутентификации на основе учетных данных должна быть формализована, а конфиденциальность учетных данных должна быть сохранена. Стремясь решить эти проблемы, в этой статье мы сначала определяем формальную модель SSO с единым определением, чтобы формально указать надежность и конфиденциальность учетных данных (Раздел II). Затем, после обзора схемы Чанг-Ли SSO в разделе III и сигнатуры Шнорра [13] в разделе IV, мы улучшаем схему Чанга-Ли, используя сигнатуру Шнорра в разделе V из-за ее простоты и неподделанности [14], [15], в то время как сохраните сеансовый ключ Чанг-Ли, часть

Краткое содержание — Распределенные системы и сети были приняты телекоммуникациями, удаленным образованием, предприятиями, армиями и правительствами.Широко применяемый метод для распределенных систем и сетей — это единый вход (SSO), который позволяет пользователю использовать единые безопасные учетные данные (или токен) для доступа к нескольким компьютерам и системам, в которых у него / нее есть разрешения на доступ. Однако формально не доказано, что большинство существующих схем единого входа удовлетворяют конфиденциальность учетных данных и надежность аутентификации на основе учетных данных. Чтобы преодолеть этот недостаток, мы формализуем модель безопасности схемы единого входа с аутентифицированным обменом ключами. В частности, мы указываем на разницу между надежностью и конфиденциальностью учетных данных и определяем их вместе в одном определении.Кроме того, мы предлагаем доказуемо безопасную схему аутентификации с единым входом, которая обеспечивает надежность, сохраняет конфиденциальность учетных данных, обеспечивает анонимность пользователя и поддерживает обмен сеансовыми ключами. Предлагаемая схема очень эффективна и подходит для мобильных устройств в распределенных системах и сетях. Ключевые слова: единый вход, распределенные системы и сети, надежность, аутентификация, информационная безопасность.

I. ВВЕДЕНИЕ С широким распространением распределенных компьютерных сетей, различные сетевые службы приобрели важность и популярность в последние несколько лет [1] [2].Следовательно, аутентификация пользователя [3] широко используется в распределенных компьютерных сетях для идентификации законного пользователя, которому требуется доступ к сетевым службам. Чтобы предотвратить подделку серверов, следует учитывать взаимную аутентификацию, а также обычно требуется установление сеансового ключа. Кроме того, в распределенных вычислительных средах может быть желательна конфиденциальность пользователей, поскольку некоторые организации могут злоупотреблять информацией, которой обмениваются, в маркетинговых целях [4]. Однако разработка эффективных и безопасных протоколов взаимной аутентификации является сложной задачей в компьютерных сетях.Более того, с увеличением использования сетевых услуг пользователю может потребоваться поддерживать все больше и больше пар идентификаторов / паролей для доступа к различным поставщикам распределенных услуг, что налагает бремя на пользователей и поставщиков услуг, а также накладные расходы на связь в компьютерных сетях. Механизм единого входа (SSO) [5] обеспечивает хорошее решение этой проблемы, поскольку он позволяет пользователю с единственными учетными данными получить доступ к нескольким поставщикам услуг. Интуитивно понятно, что существует три основных требования безопасности для схем единого входа, а именно полнота, надежность и конфиденциальность учетных данных [16], [6].Однако, насколько нам известно, надежность официально не изучена 978-0-7695-4745-9 / 12 $ 26.00 © 2012 IEEE DOI 10.1109 / TrustCom.2012.228

271

без изменений. Безопасность предлагаемого протокола обсуждается в разделе VI. Наконец, раздел VII завершает эту статью. II. ФОРМАЛЬНАЯ МОДЕЛЬ В этом разделе мы представляем формальную модель для определения схемы единого входа при обмене ключами с аутентификацией (AKESSO) и ее требований к безопасности. Специально перечислим компоненты (например,грамм. синтаксис) AKESSO, определить правильность, описать модель противника и формально указать три свойства безопасности, включая безопасную аутентификацию пользователя на основе учетных данных, безопасную аутентификацию поставщика услуг на основе учетных данных и безопасность сеансового ключа.

: это протокол обмена ключами, выполняемый пользователем Ui с частным вводом Ci и поставщиком услуг Pj с частным вводом SKj. После завершения каждого экземпляра протокола Ui выведет сеансовый ключ Kij, если он / она принимает Pj. Точно так же после завершения каждого экземпляра протокола Pj выведет сеансовый ключ Kji, если он принимает Ui.(В идеале ожидается, что Kij и Kji будут иметь одно и то же значение.)

Замечание 1. Приведенное выше определение фокусируется на AKESSO на основе открытого ключа с неинтерактивными доказательствами. Его можно расширить для поддержки интерактивных доказательств, когда spi и sspj генерируются интерактивными протоколами, выполняемыми пользовательским интерфейсом пользователя и поставщиком услуг Pj. Однако определение AKESSO на основе симметричного ключа — это отдельная история, которая выходит за рамки данной статьи.

Определение 1. Схема единой регистрации с обменом ключами с аутентификацией (AKESSO) включает доверенного поставщика учетных данных T CP, группу поставщиков услуг P и группу пользователей U.Он состоит из восьми алгоритмов и одного протокола: алгоритм инициализации Init (·), алгоритм генерации идентификаторов IdGen (·), алгоритм генерации учетных данных CGen (·), алгоритм проверки учетных данных CV er (·), алгоритм создания пользовательских доказательств UP Gen (·) , алгоритм проверки подлинности пользователя UPV er (·), алгоритм создания доказательства поставщика услуг SP P Gen (·) и алгоритм проверки доказательства поставщика услуг SP PV er (·), а также протокол обмена ключами.

Замечание 2. По сравнению с формальной моделью Хана и др., Приведенной в [16], нам требуется обмен ключами в AKESSO, и каждому пользователю не нужно иметь пару открытого / закрытого ключей.Однако в определении Хана и др. TCP (называемый в их статье IdP) менее надежен, поскольку он не сможет выдавать себя за какого-либо пользователя: каждый пользователь будет запускать протокол с нулевым разглашением, чтобы показать, что он / она знает закрытый ключ. соответствующий публичному ключу, встроенному в его / ее учетные данные. Прежде чем формально определять свойства безопасности, мы, естественно, требуем, чтобы AKESSO был правильным. А именно, учетные данные Ci, сгенерированные доверенным поставщиком учетных данных T CP, будут действительными, подтверждение пользователя upi, выданное должным образом пользователем ui, имеющим действительные учетные данные Ci, будет принято поставщиком услуг Pj в соответствии с алгоритмом UPV er, доказательством поставщика услуг. sppj, правильно выданный Pj, будет принят пользователем Ui в соответствии с алгоритмом SP PV er, а Ui и Pj будут принимать друг друга и выводить один и тот же сеансовый ключ, если они честно используют протокол обмена ключами.Формально мы определяем правильность следующим образом.

1) Init (λ): принимая параметр безопасности λ0 (или λ1) в качестве входных данных, выводит пару открытого / закрытого ключей (P K, SK) для T CP (или (P Kj, SKj) для Pj ∈ P). 2) IdGen (RIi): принимая регистрационную информацию RIi в качестве входных данных, выводит уникальный идентификатор IDi для пользователя Ui ∈ U. 3) CGen (IDi, SK): принимая идентификационный IDi и закрытый ключ SK T CP в качестве входных данных, выводит учетные данные Ci для пользователя Ui. 4) CV er (Ci, IDi, P K): принимая учетные данные Ci, идентификационный IDi и открытый ключ P K T CP в качестве входных данных, выдает «1» или «0» для принятия или отклонения учетных данных Ci соответственно.5) UP Gen (Ci, IDi, PK, M): принимая учетные данные Ci, идентификационный IDi, открытый ключ PK T CP и временное сообщение M, сгенерированное в сеансе, в качестве входных данных, выводит подтверждение пользователя upi, показывающее пользователя Ui знание учетных данных Ci. 6) UPV er (upi, IDi, PK, M): принимая в качестве входных данных подтверждение пользователя, идентификатор IDi, открытый ключ T CP и временное сообщение M, сгенерированное в сеансе, выдает «1» или « 0 ”для принятия или отклонения UPI в качестве действительного документа, подтверждающего учетную запись идентичность IDi соответственно.7) SP P Gen (SKj, M): принимая закрытый ключ SKj поставщика услуг Pj и временное сообщение M, сгенерированное в сеансе, в качестве входных данных, выводит доказательство поставщика услуг sppj, показывающее, что Pj знает SKj. 8) SP PV er (sppj, P Kj, M): принимая доказательство поставщика услуг sppj, открытый ключ P Kj Pj и временное сообщение M, сгенерированное в сеансе, в качестве входных данных, выводит «1» или «0» для принятие или отклонение sppj в качестве действительного доказательства поставщика услуг по открытый ключ P Kj соответственно.

Определение 2.(Корректность) Схема AKESSO называется правильной, если она удовлетворяет всем следующим условиям: 1) Для любого RIi и любой пары ключей (PK, SK), если IDi ← IdGen (RIi) и Ci ← CGen (IDi, SK), то CV er (Ci, IDi, PK) = 1. 2) Для любого IDi, любой пары ключей (PK, SK) и любого M, если Ci ← CGen (IDi, SK) и upi ← UP Gen (Ci, IDi, PK , M), то UPV er (upi, IDi, PK, M) = 1. 3) Для любой пары ключей (P Kj, SKj) и любого ← SP P Gen (SKj, M), то M, если sppj SP PV er (sppj, P Kj, M) = 1. 4) Для любого пользователя Ui с действующими учетными данными Ci и поставщика услуг Pj с закрытым ключомSKj, если они оба честно используют протокол обмена ключами, то они примут друг друга и выведут тот же ключ сеанса, т.е.е., Kij = Kji. Неформально схема AKESSO является безопасной, если все желаемые функции, указанные в приведенном выше определении, могут выполняться только соответствующими объектами, то есть не злоумышленниками, которые

272

Замечание 4. O4 имитирует реальную среду для активного атакующего. A, который может получить закрытый ключ SKj поставщика услуг Pj, отправить сообщение m как поток сообщений f ∈ {0, 1, · · ·, n} целевому пользователю Ui и затем получить соответствующий ответ. Чтобы ответить этому оракулу, Ui сгенерирует свой ответ в соответствии со спецификацией протокола и отправит его A.Заметим, что если Ui не получил все необходимые предыдущие сообщения, которые соответствуют этому сообщению с потоком сообщений f, этот запрос оракула будет отклонен, поскольку он бессмысленен для злоумышленника с точки зрения Ui. Фактически, O4 также предоставляет доступ к Oracle Oracle по алгоритму U P Gen (·), поскольку U, P каким-то образом запускает U P Gen (·) при выполнении. В нашей конструкции U P Gen (·) — алгоритм генерации подписи Шнорра. В этом случае, с одной стороны, оракул O4 может быть не сильнее подписывающего оракула в Game-UFCMA, рассмотренном в разделе IV, поскольку временное сообщение M, один вход алгоритма UP Gen (·), может быть совместно решено Ui и А (играющий роль некоего Пи), а не только А.Таким образом, для A может быть сложно получить пользовательское подтверждение Ui для любого произвольного сообщения M. С другой стороны, противник A может быть не слабее фальсификатора в GameUFCMA, поскольку помимо O4 мы также предлагаем другие запросы оракула, которые могут увеличить возможности A. Мы опускаем аналогичное замечание, которое относится к O5.

имеют доступ ко всем возможным ресурсам в строго определенной модели противника. Фактически, мы определим безопасность аутентификации SSO, которая соответствует пунктам 1) — 3), и конфиденциальность сеансового ключа, которая соответствует пункту 4).Чтобы дополнительно определить эти свойства безопасности, мы определяем модель противника следующим образом: Пусть T CP будет оракулом доверенного i-го органа с его парой ключей (SK, PK), U, P будет пользовательским оракулом, моделирующим набор всех зарегистрированных пользователей, взаимодействующих j с оракулом поставщика услуг в сеансе i, а P, U — оракул поставщика услуг, моделирующий набор всех зарегистрированных поставщиков услуг, взаимодействующий с оракулом пользователя в сеансе j. Противник A с вероятностным полиномиальным временем (PPT) может задать следующие запросы оракула.1) O 1: Register (, U) — после получения этого запроса T CP будет запускать алгоритмы IdGen (RIAi) и CGen (IDAi, SK) и выводить новый идентификатор пользователя IDAi с соответствующими учетными данными CAi в A, который может проверить учетные данные, запустив CV er (·). 2) O2: Регистр (, P) — После получения этого запроса система запустит Init (λ1) и выведет пару закрытого / открытого ключей PAj (SKAj, P KAj) вместе с идентификатором SIDAj в A. 3) O3: Execute (Ui, Pj) — Получив этот запрос, ji U, P и P, U выполнят протокол как Ui и Pj in соответственно.Обмен сообщениями между ними будет записан и отправлен в A. Здесь мы требуем, чтобы учетные данные Ui и закрытый ключ Pj не были повреждены A через оракулы O1 и O2. 4) O4: Send (Ui, m, f) — этот запрос отправляет сообщение m как i поток сообщения f ∈ {0, 1, · · ·, n} пользовательскому оракулу U, P, который имитирует пользователя U i, а затем оракул честно вычисляет сообщение и отправляет ответы обратно в A, где n — общее количество сообщений, переданных в протоколе. Если пользователь является инициатором протокола по умолчанию, A также может начать новый сеанс, запросив Отправить (Ui, ∅, 0), где ∅ обозначает пустой набор.5) O5: Send (Pj, m, f) — этот запрос отправляет сообщение m как i message flow f ∈ {0, 1, · · ·, n} пользователю оракулу Pj, а затем P, U, который имитирует поставщик услуг, в котором оракул честно вычисляет сообщение и отправляет ответы обратно в A. Если поставщик услуг является инициатором протокола по умолчанию, A также может начать новый сеанс, запросив Отправить (P j,, 0). 6) O6: Reveal (, i) — этот запрос моделирует утечку ключа сеанса в сеансе i. Этот запрос может быть задан только в том случае, если ключ сеанса был совместно использован поставщиком услуг и пользователем в сеансе i.

Чтобы формально определить надежность и конфиденциальность учетных данных, мы сначала обсудим разницу между надежностью и конфиденциальностью учетных данных, поскольку в большинстве существующих схем учитывается только конфиденциальность учетных данных. Конфиденциальность учетных данных требует невозможности подделки и невозможности восстановления. Первый гарантирует, что любой злоумышленник PPT A имеет лишь незначительную вероятность успешного создания действительных учетных данных Ct целевого пользователя Ut на этапе генерации учетных данных, в то время как второй требует, чтобы на этапе аутентификации пользователя любой A мог восстановить Ct только с незначительным вероятность.Надежность также имеет решающее значение на этапе аутентификации пользователя, поскольку она гарантирует, что любой A без действительных учетных данных может только сгенерировать подтверждение пользователя, которое проходит через аутентификацию пользователя с незначительной вероятностью. Существующие исследования [16], [12] сосредоточены только на том, могут ли действительные учетные данные быть подделаны или восстановлены злоумышленниками, но не рассматривают, действительно ли действительные учетные данные необходимы для создания действительного пользовательского доказательства. Мы определим эти три свойства как одно определение (одно для пользователей и одно для поставщиков услуг).Пусть AO обозначает противника A, который имеет доступ ко всем запросам оракула в O = {Oi | i = 1, 2, · · ·, 6} в модели противника; пусть держатель удостоверения Ui с идентификатором IDi и удостоверением Ci, и поставщик услуг Pj с идентификатором SIDj и парой ключей (SKj, P Kj) являются двумя машинами Тьюринга с полиномиальным временем. Пусть Ui и Pj взаимодействуют друг с другом и поместите A между Ui и Pj. обозначает незначительную функцию. Мы определяем безопасную аутентификацию пользователя на основе учетных данных следующим образом:

Замечание 3. O3 имитирует реальную среду для пассивного атакующего A, который может подслушивать все сообщения, которыми обмениваются между Ui и Pj при выполнении протокола.Если A знает ключ SKj, Oracle O3 — это учетные данные Ci для Ui, а личные данные Pj не нужны, поскольку A может запускать протокол сам по себе от их имени. Если A знает один из этих двух секретов, но не оба, A может запустить протокол с Ui (Pj), секрет которого не раскрывается посредством выполнения oracle O4 (O5).

Определение 3. (Безопасная аутентификация пользователя на основе учетных данных (SCU A)) Схема AKESSO обеспечивает безопасную аутентификацию пользователя на основе учетных данных, если какой-либо злоумышленник PPT A имеет незначительное преимущество Adv SCU A (AO) для создания действительного доказательства пользователя без хранения соответствующие учетные данные.Формально

273

III. ОБЗОР СХЕМЫ C HANG -L EE

для любого PPT A, Adv SCU A (AO) = Pr [(IDt, upt, M) ← AO | UPV er (upt, IDt, PK, M) = 1 ] ≤ со следующими ограничениями: • •

В 2012 году Чанг и Ли [12] предложили улучшенную эффективную схему идентификации удаленного пользователя для пользователей мобильных устройств, в которой используется метод единой регистрации, поддерживается установка сеансового ключа и сохраняется пользователь анонимность. Однако схема не обеспечивает конфиденциальность и надежность учетных данных из-за [6].В этом разделе мы кратко рассмотрим схему Чанга-Ли и ее недостатки.

A не получил учетные данные Ct, соответствующие IDt, через O1 — Register (, U) oracle; и A не получил никакого действительного подтверждения пользователя для сообщения M, запросив какой-либо оракул в O, в частности, O3 и O4.

Аналогичным образом определение аутентификации безопасного поставщика услуг приведено ниже:

A. Обзор схемы Схема SSO Чанг-Ли состоит из трех этапов: инициализация системы, регистрация и идентификация пользователя.Подробности следующие. 1) Фаза инициализации системы: доверенный орган T CP определяет пару ключей RSA (e, d) и генератор g и публикует общедоступные параметры. 2) Этап регистрации: на этом этапе доверенный орган подписывает подпись RSA Si = (IDi || h (IDi)) d mod N для пользователя Ui в качестве учетных данных. Для каждого поставщика услуг Pj он должен поддерживать свои собственные общедоступные параметры RSA (IDj, ej, Nj) и частный параметр dj, аналогичные T CP. 3) Этап идентификации пользователя: на этом этапе сеансовым ключом является Kij = h (IDi || kij), где kij — простой сеансовый ключ дифференциала-Хеллмана.Для идентификации поставщиков услуг использовалась схема подписи RSA; для аутентификации пользователя (K || k || n) пользователь должен предоставить доказательство z = Si ij 2 2 mod N учетных данных Si, где k2 — материал сеансового ключа пользователя, а n2 — случайный одноразовый номер, выбранный пользователем. . В целях анонимности случайный одноразовый номер n3 и идентификатор пользователя, которые использовались для проверки, были зашифрованы с помощью схемы шифрования с симметричным ключом с сеансовым ключом Kij (рассматриваемым как ключ шифрования). Пользователь может пройти аутентификацию h (K || k || n), если z e mod N = SIDi ij 2 2 mod N доза удерживается, и пользователь полагает, что они используют один и тот же сеансовый ключ, если был получен хешированный n3.

Определение 4. (Безопасная аутентификация поставщика услуг (SSP A)) Схема AKESSO обеспечивает безопасную аутентификацию поставщика услуг, если какой-либо злоумышленник PPT A имеет незначительное преимущество Adv SSP A (AO) для подделки действительного доказательства поставщика услуг без наличия соответствующего закрытый ключ поставщика услуг. Формально для любого PPT A Adv SSP A (AO) = Pr [(P Kt, M, sppt) ← AO | SP PV er (P Kt, M, sppt) = 1] ≤ со следующими ограничениями: A не имеет получил закрытый ключ SKt, соответствующий SIDt, через O2 — Register (, P) oracle; • A не получил никакого действительного подтверждения поставщика услуг sppt для сообщения M, запросив какой-либо оракул в O, в частности, O3 и O5.Здесь мы рассмотрим актуальность и тестовый запрос T est (, i) для определения безопасности сеансового ключа [17]. Злоумышленник может получить ключи сеанса, запросив O6. Мы говорим, что ключ сеанса свежий тогда и только тогда, когда запрос O6 не был запрошен w.r.t. эту сессию. Другими словами, новый сеансовый ключ должен быть неизвестен противнику. Для простоты мы называем тестовый запрос O7, что представляет собой игру, определяемую следующим образом: ii • O7 — T est (, i): в протоколе, если U, P и P, U принимают и используют один и тот же новый сеансовый ключ в сеанс i, получив этот запрос, подбрасывая монету b, возвращается правильный сеансовый ключ, если b = 0, в противном случае повторяется случайный сеансовый ключ.Только A может запросить этот запрос один раз, и A должен вывести один бит b в результате угадывания b. Преимущество A в атаке на безопасность сеансового ключа (SKS) протокола определяется как SKS (AO) = | 2 Pr [b = b] -1 |, где O = O∪ {O7}. Adv •

B. Обзор атак Две высокорисковые атаки идентифицированы в [6] по схеме ChangLee. Первый позволяет злоумышленнику Pj восстановить учетные данные пользователя; последний позволяет злоумышленнику пройти аутентификацию пользователя без действительных учетных данных. Они кратко рассмотрены ниже.1) Атака с восстановлением учетных данных: пользователь Ui может пройти аутентификацию, если он предоставит действительное доказательство z знания Ci. Чтобы упростить обсуждение, мы используем h3 для обозначения h (Kij || k2 || n2). Итак, доказательство z = Sih3. Легко видеть, что для разных доказательств в разных сеансах одни и те же учетные данные Si были зашифрованы несколько раз с разными h3, но одним и тем же модулем N. Таким образом, если к злоумышленнику Pj дважды обращались с одним и тем же пользователем Ui, то Pj может восстановить учетные данные Si, используя расширенный алгоритм Евклида.Предположим, что (z, z) и (h3, h3), доказательства и хеш-значения в двух разных сеансах, удовлетворяют gcd (h3, h3) = 1. Тогда мы можем найти два целых числа a и b такие, что a · h3 + b · h3 = 1 (в Z) благодаря расширенному алгоритму Евклида. Наконец, Pj может восстановить учетные данные пользователя путем вычисления z a · z b

Безопасность сеансового ключа [17] моделирует неспособность злоумышленника A отличить реальный сеансовый ключ от случайной строки, как формально определено ниже. Определение 5. (Безопасность сеансового ключа) Мы говорим, что AKESSO удовлетворяет требованиям безопасности сеансового ключа, если для любого злоумышленника A PPT SKS (AO) ≤, где O = O ∪ {O7}.Adv Наконец, мы можем дать определение схемы единого входа с безопасным обменом ключами с аутентификацией. Определение 6. (Схема единого входа с безопасным обменом ключами с аутентификацией): Схема AKESSO называется безопасной, если она верна и удовлетворяет требованиям безопасности SCU A, SSP A и сеансового ключа.

274

h · a + h · b

ТАБЛИЦЫ, ИСПОЛЬЗУЕМЫЕ В СХЕМЕ

2 mod N = Si 2 mod N = Si. Успешность этой атаки составляет около 60% [6]. 2) Атака олицетворения без учетных данных: в этой атаке предполагается небольшой открытый ключ RSA e, где для «малого» требуется, чтобы двоичная длина e была намного меньше выходной длины хэш-функции h.Рациональность этого предположения изложена в [6]. В разговоре, если h3 делится на e, то противник вычисляет целое число b такое, что h3 = e · b, и вычисляет доказательство z по z = SIDib, где SIDi = IDi || h (IDi). Проверка выполняется как SIDih3 mod N = SIDib · e mod N = z e mod N. Таким образом, злоумышленник может пройти аутентификацию пользователя без действительных учетных данных. Вероятность успеха атаки составляет около 1 / е [6].

T CP Pj Ui SIDj IDi Ci xy Ek (M) Dk (C) h (·)

Доверенный поставщик учетных данных Поставщик услуг Пользователь Уникальная идентичность Pj Уникальная идентичность Ui Учетные данные Ui Долгосрочная перспектива закрытый ключ T CP Открытый ключ T CP Симметричное шифрование сообщения M с использованием ключа k Симметричное дешифрование зашифрованного текста C с использованием ключа k Защищенная хеш-функция

proof не может обеспечить надежность и конфиденциальность учетных данных, в то время как подпись Шнорра может.В качестве доказуемо неподдельной схемы подписи [21] подпись Шнорра позволяет подписывающему лицу аутентифицировать себя, подписывая сообщение, не раскрывая никакой другой полезной информации о своем закрытом ключе подписи. В предложенной схеме T CP сначала выдает учетные данные для каждого пользователя, подписывая идентификатор IDi пользователя в соответствии с подписью Шнорра. Затем, рассматривая свои учетные данные как другую пару открытого / закрытого ключей, пользователь может аутентифицировать себя, подписав подпись Шнорра на временном сообщении, созданном в протоколе.Напротив, каждый поставщик услуг поддерживает свою собственную пару открытого / закрытого ключей в любой схеме защищенной подписи, чтобы он мог аутентифицировать себя для пользователей, просто выдав обычную подпись. Наконец, как и в схеме Чанга-Ли [12], сеансовый ключ устанавливается путем выполнения варианта протокола обмена ключами Диффи-Хеллмана, а анонимность пользователя гарантируется за счет шифрования с симметричным ключом. Обозначения, используемые в схеме, приведены в таблице I. Этап настройки системы: на этом этапе T CP инициализирует свои общие и частные параметры как схему подписи Шнорра.Сначала T CP выбирает большие простые числа p и q такие, что q | p — 1, выбирает генератор g большого безопасного простого порядка q в циклической группе G. Затем T CP устанавливает свой закрытый ключ SK = x, где x ∈ Z ∗ q — случайное число и публикует свой открытый ключ PK = y, где y = gx mod p. Этап регистрации: на этом этапе пользователь запрашивает у T CP регистрацию, затем T CP выдает уникальный идентификатор IDi через IdGen (RIi) и подписывает подпись Шнорра (a, e, C) для идентификации пользователя в качестве алгоритма генерации учетных данных CGen (IDi, СК). C хранится в секрете пользователем, а (a, e) будет обнародован.Подробности приведены ниже.

IV. ОБЗОР ИГНАТУРЫ ШНОРРА Как одна из простейших, кратчайших и часто используемых схем подписи, схема подписи Шнорра [18], [13] доказуемо безопасна в случайной модели оракула в предположении, что проблема дискретного логарифмирования неразрешима [19 ], [20], [21], [15]. Теперь мы рассмотрим схему подписи Шнорра следующим образом. Инициализация: схема определена в циклической группе G порядка q с образующей g ∈ Z ∗ p, где p и q простые числа, такие что q | p — 1, q ≥ 2160 и p ≥ 21024.Также выбирается безопасная хеш-функция h (·). Генерация подписи: чтобы подписать сообщение m закрытым ключом x ∈ Z ∗ q, подписывающая сторона выбирает случайность r ∈ Z ∗ q и выводит подпись (a, e, s), вычисляя a = gr mod p, e = h (a, m) и s = r + x · e mod q. Проверка подписи: Имеется подпись (a, e, s) для сообщения m w.r.t. открытый ключ y = g x mod p, верификатор принимает эту подпись, если e ≡ h (a, m) и g s ay e mod p. Обозначим Init (λ), SGen (·) и SV er (·) — алгоритм инициализации, алгоритм подписи и алгоритм проверки, соответственно.Формально схема подписи называется экзистенциально неподделанной, если для любого алгоритма подделки PPT A она может выиграть только следующую игру, называемую Game-UFCMA, с пренебрежимо малой вероятностью [22] [23]. • Настройка: (pk, sk) ← Init (λ). При заданном параметре безопасности λ пара открытый / закрытый ключ генерируется алгоритмом инициализации, а противнику A выдается открытый ключ pk. • Запрос: σi ← SGen (sk, mi). A запускается до q раз, чтобы адаптивно запросить оракула подписи подписи. Каждый раз подписывающий оракул будет отвечать подписью σi для каждого сообщения mi, выбранного A, где 1 ≤ i ≤ q.• Forge: A выводит новую пару сообщения и подписи (mj, σj). A выигрывает, если 1) SV er (pk, mj, σj) = 1, т.е. σj является действительной подписью для сообщения mj под открытым ключом pk. 2) mj = mi для любого i ∈ {1, · · ·, q}.

•

V. ПОВЕРХНОСТНАЯ СХЕМА

•

В этом разделе представлена безопасная схема единого входа с анонимностью пользователя для удаленной аутентификации пользователей в распределенных системах и сетях. Мы используем подпись Шнорра [18] [13], чтобы преодолеть недостатки схемы Чанг-Ли, поскольку их пользователь

275

Регистрация пользователя: когда пользователь Ui запрашивает регистрацию, T CP выбирает уникальный идентификатор IDi и генерирует учетные данные Ci = (a, e, C) для Ui путем выбора случайности r ∈ Z ∗ q и вычисления a = gr mod p, e = h (a, IDi) и C = r + xe mod q.Затем T CP отправляет идентификатор IDi и учетные данные Ci, которые являются подписью Шнорра для IDi, пользователю Ui, где C должен храниться в секрете. Регистрация поставщика услуг: каждый Pj поддерживает пару открытого / закрытого ключей (P Kj, SKj) любой защищенной схемы подписи. Здесь алгоритмы SP P Gen (·) и SP P V er (·) идентичны алгоритмам генерации и проверки подписи соответственно.

(Req, n1) g r1 mod p

M2 (k1, v, n2) u

h (k1 || SID j || n1)

SPPGen (SK j, u)

h (k1 || SID j || n1)

SPPVer (PK j, u, v) r

k ij

k1 2 mod

g r2 mod

K ij

подписывает Kij, используя его / ее секретный пароль C, вычисляя ei = h (k2, Kij), z = r2 + Cei mod q и ω = EK (IDi || n3 || n2 | | e || a), где n3 — одноразовый номер, выбранный Ui.Наконец, Ui отправляет M3 = (ω, z, k2) поставщику услуг Pj. 4) Чтобы проверить z, Pj сначала вычисляет kij = k2r1 mod p, выводит сеансовый ключ Kij = h (SIDj || kij) и расшифровывает ω с помощью Kij, чтобы восстановить IDi || n3 || n2 || e || a. Затем Pj проверяет, является ли e = h (a || IDi). Если это не так, Pj прерывает протокол. В противном случае поставщик услуг вычисляет ei = h (k2, Kij) и проверяет z, проверяя, является ли g z = k2 · aei · (y e) ei mod p. Если это так, Pj принимает аутентификацию Ui, считает, что они использовали один и тот же сеансовый ключ Kij, и отправляет V = h (n3) как M4 в Ui.5) Пользовательский интерфейс вычисляет V = h (n3) и проверяет, является ли V = V. Если это так, Ui считает, что он / она поделился тем же сеансовым ключом Kij с Pj.

h (SID j || k ij)

h (k 2, K ij)

r2 C ˜ ei

EK ij (ID i || n3 | | n 2 || e || a)

M3 (Z, z, k2)

kij

k 2 1 mod p

K ij

h (SID j || kij)

( IDi || n3 || n2 || e || a) e

ei gz

M4 (V) V ‘V’

DKij (Z)

h (a || IDi)

VI.АНАЛИЗ БЕЗОПАСНОСТИ Предлагаемая схема использует схему подписи Шнорра [18] [13] для генерации учетных данных для пользователей, использует модифицированную схему обмена ключами Диффе-Хеллмана для установления сеансового ключа, подписывает подпись Шнорра на хешированном сеансовом ключе для аутентификации пользователя, использует любые безопасная схема подписи для аутентификации сервера и использует шифрование с симметричным ключом для обеспечения анонимности пользователя. Схема единого входа с безопасным обменом ключами с аутентификацией (AKESSO) требует безопасной аутентификации пользователя на основе учетных данных (SCU A), безопасной аутентификации поставщика услуг (SSP A) и безопасного сеансового ключа.Чтобы доказать безопасность предлагаемого AKESSO, мы просто докажем SCU A и SSP A, потому что (1) предлагаемая схема улучшает только части генерации ключей, аутентификации пользователя и аутентификации поставщика услуг в схеме Чанга-Ли [12], в то время как части анонимность пользователя и установка сеансового ключа не изменились; анонимность пользователя и безопасность сеансового ключа были доказаны в [12] и обсуждались в [6] без выявления каких-либо проблем. Теперь приступим к формальному анализу защищенности предложенной схемы AKESSO.

ч (k 2, K ij)?

k 2 ˜ a ei ˜ (y e) ei h (n3)

h (n3)?

Рис. 1.

Фаза идентификации участника

Фаза аутентификации: на этом этапе для аутентификации пользователь Ui подписывает подпись Шнорра вновь установленным сеансовым ключом Kij, используя учетные данные C как ключ подписи, а Ui ‘ s материал сеансового ключа k2 используется как обязательство. Обратите внимание, что соответствующий ключ проверки C — это g C, который можно восстановить, вычислив g C = a · y e mod p.Для аутентификации поставщика услуг любая доказуемо безопасная схема подписи может использоваться для аутентификации поставщика услуг в предлагаемой схеме. Ключ сеанса устанавливается с использованием модифицированной схемы обмена ключами Диффи-Хеллмана, которая была формально доказана в [12], а анонимность и несвязанность пользователя сохраняются за счет использования шифрования с симметричным ключом для шифрования a, e и идентификатора пользователя IDi. Детали этого этапа показаны на Рисунке 1 и поясняются ниже.

Теорема 1.(Правильность) Предлагаемая конструкция является правильной схемой AKESSO в соответствии с определением 2. Доказательство: это можно напрямую проверить в соответствии с определением 2, приведенным в разделе II.

1) Пользователь Ui выбирает случайный одноразовый номер n1 и отправляет M1 = (Req, n1) в Pj, где Req — это запрос на обслуживание. 2) Получив (Req, n1), Pj выбирает случайное число r1 ∈ Z ∗ q, вычисляет материал своего сеансового ключа k1 = g r1 mod p, u = h (k1 || SIDj || n1) и подписывает u, чтобы получить подпись v = SP P Gen (SKj, u) и отправляет пользователю M2 = (k1, v, n2).3) Пользователь Ui сначала вычисляет u = h (k1 || SIDj || n1) и проверяет подпись v, проверяя, является ли SP PV er (P Kj, u, v) = 1. Если вывод равен «0», Ui завершает работу. протокол. В противном случае Ui принимает аутентификацию поставщика услуг Pj, а затем выбирает случайное число r2 ∈ Z ∗ q для вычисления k2 = g r2 mod p, kij = k1r2 mod p и сеансового ключа Kij = h (SIDj || kij ). После этого Ui

Неформально предлагаемая схема AKESSO гарантирует SSP A, поскольку каждый поставщик услуг использует схему безопасной подписи.Чтобы доказать SCU A, нам нужно показать, что определение 3 выполняется для предложенной схемы AKESSO, предполагая неподделанность схемы подписи Шнорра. Теорема 2. (Безопасная аутентификация пользователя на основе учетных данных) В предлагаемой схеме AKESSO, если есть злоумышленник PPT A, который имеет немаловажное преимущество Adv SCU A (AO), как указано в Определении 3, тогда схема подписи Шнорра может быть подделана под UF. CM A атакует, как определено в Разделе IV. Доказательство: поскольку противник A, имеющий доступ ко всем оракулам в O = {O1, · · ·, O6}, имеет немаловажное преимущество

276

Adv SCU A (AO), согласно Определению 3 это означает, что при верен по крайней мере один из следующих двух случаев: O • Случай (1): с не пренебрежимо малой вероятностью 1 A может вывести учетные данные Ct, соответствующие незарегистрированному IDt целевой идентичности.O • Случай (2): с не пренебрежимо малой вероятностью 2 A может подделать действительное пользовательское доказательство для нового сообщения M w.r.t. зарегистрированный целевой идентификатор IDi. Теперь мы докажем, что если истинен либо случай (1), либо случай (2), мы можем построить алгоритм B, который способен нарушить неподдельность сигнатуры Шнорра, где B запускает AO как подпрограмму для достижения своей цели. .

Алгоритм создания доказательства для зарегистрированного целевого пользователя Ut с идентификатором IDt. Подробности приведены ниже. Предположим, что B задана целевая схема подписи Шнорра с параметром (p, q, h (·)) и открытым ключом y = g x mod p, где частный ключ x неизвестен B.Во-первых, B устанавливает y = g x mod p в качестве открытого ключа T CP, выбирая случайное число x в качестве частного ключа T CP. Для любого идентификатора IDi, за исключением целевого идентификатора IDt, для ответа на запрос O1 B может напрямую выдать учетные данные Ci для IDi путем генерации подписи Шнорра для IDi, поскольку B знает закрытый ключ x T CP. Напротив, B примет (a, e, x) в качестве учетных данных Ct для целевого идентификатора IDt, где e ∈ {0, 1, · · ·, q — 1} — случайное число, a ∈ Z ∗ p установлено как a = y · y −e mod p, а h (a, IDt) задано как e.x h (e, IDt) mod p. Обратите внимание, что B не знает. Итак, у нас g = a y известно значение x, и не потребуется раскрывать Ct для A, потому что IDt — это целевое удостоверение. Кроме того, здесь мы можем искусственно исправить хеш-значение для такого специального входа (a, IDt), потому что подпись Шнорра защищена в случайном оракуле, где хеш-функция может рассматриваться как случайная функция [21]. Все другие оракулы в O можно моделировать, как в случае (1), за исключением того, что A запрашивает запросы O3 и O4, в которых участвует Ut с идентификатором IDt.В таких сценариях B может моделировать Ut для вывода действительного подтверждения пользователя upt w.r.t. учетные данные Ct, выполнив весь протокол или запустив одно движение с необходимой помощью из собственного подписывающего оракула w.r.t. открытый ключ y. Опять же, нетрудно увидеть, что смоделированная выше система неотличима от реальной системы с точки зрения A. Следовательно, с вероятностью 2 A сможет вывести действительное подтверждение пользователя upt для сообщения M w.r.t. IDt целевой идентичности, где M не запрашивается в запросах O3 и O4.Следовательно, B может просто переслать upt как поддельную подпись Шнорра для сообщения M. Поскольку M не запрашивается в запросах O3 и O4, A не запрашивает M в своем подписывающем оракуле, т. Е. M является новым сообщением для B. Итак, пара поддельного сообщения-подписи B (upt, M) действительна в соответствии с определением Game-UFCMA (см. Раздел IV). Более того, показатель успеха B точно такой же, как у A, то есть 2, что немаловажно. Следовательно, это означает, что B успешно преодолевает неподкупность схемы подписи Шнорра.

Чемодан (1). Предположим, что B задана целевая схема подписи Шнорра с параметром (p, q, h (·)) и открытым ключом y = gx mod p, где закрытый ключ x неизвестен B. Стратегия B по выигрышу Game-UFCMA с Немаловажная вероятность состоит в том, чтобы настроить схему AKESSO для A и смоделировать оракулов в O таким образом, чтобы A не мог различить разницу между этой моделируемой средой и реальной схемой AKESSO. Следовательно, A сможет успешно получить учетные данные Ct для незарегистрированного идентификатора IDt с вероятностью 1.После этого B может адаптировать эти учетные данные в поддельную подпись Шнорра для нового сообщения и, таким образом, нарушить несостоятельность схемы подписи Шнорра. Теперь мы опишем, как B устанавливает такую смоделированную схему AKESSO для A. Сначала B устанавливает y как открытый ключ T CP и передает y для B. Затем каждый оракул в Oi (i = 1, · · ·, 6) можно смоделировать следующим образом. Чтобы смоделировать запрос O1, B может попросить свой собственный оракул подписи получить подпись Шнорра Ci для каждого идентификатора IDi, а затем ответить (IDi, Ci) на A. Чтобы смоделировать запрос O2, B может просто запустить Init (λ1), чтобы получить общедоступный / частный пара ключей (SKj, P Kj) для идентификатора SIDj, а затем пересылает (SIDj, SKj, P Kj) в A.Поскольку B знает учетные данные всех пользователей и закрытые ключи всех поставщиков услуг, он может имитировать оракулы O3, O4, O5 и O6, тривиально выполняя весь протокол, выполняя одно движение от имени пользователя, выполняя одно движение от имени поставщика услуг. , и раскрытие сеанса соответственно. Обратите внимание, что поскольку IDt в этом случае является незарегистрированным идентификатором, соответствующий пользователь Ut не будет задействован ни в каком оракуле Oi (i = 1, · · ·, 6). Нетрудно увидеть, что смоделированная выше система неотличима от реальной системы с точки зрения А.Следовательно, A сможет выводить учетные данные Ct для IDt целевой идентичности с немаловажной вероятностью 1, когда IDt не запрашивается в запросах O1. Следовательно, B просто пересылает Ct как поддельную подпись Шнорра для сообщения IDt. Поскольку IDt не запрашивается в запросах O1, A не запрашивает IDt в своем подписывающем оракуле, т. Е. IDt является новым сообщением для B. Таким образом, пара поддельных сообщений и подписей B (IDt, Ct) действительна в соответствии с определением Game -UFCMA (см. Раздел IV). Более того, процент успеха B в точности такой же, как у A, i.е., 1, которым нельзя пренебречь. Следовательно, это означает, что B успешно преодолевает неподкупность схемы подписи Шнорра.

Замечание 5. В случае (1) AO может напрямую подделать Ct, восстановить с помощью пользователя Ut или перехватить Ct после выполнения протокола транскрипты между Ut и некоторыми поставщиками услуг или получить Ct любым другим возможным способом, хотя AO не может получить Ct, тривиально спросив O1 oracle по IDt. Следовательно, это означает, что если наш AKESSO не удовлетворяет требованиям о неподдельности или невозможности восстановления учетных данных, то подпись Шнорра может быть подделана.Точно так же в случае (2) AO может напрямую подделать подтверждение пользователя без учетных данных Ct, наблюдать и адаптировать существующие доказательства пользователя, сгенерированные Ut, в запрос подтверждения пользователя для сообщения M или вычислить upt любым другим способом, хотя AO не позволяет получить любое пользовательское доказательство для одного и того же сообщения M, тривиально задавая оракулы O3 и O4 относительно IDt. Следовательно, это означает, что если наш AKESSO не может удовлетворить надежность аутентификации на основе учетных данных [6], то подпись Шнорра может быть подделана.

Чемодан (2).Это может быть доказано аналогично случаю (1), но B будет внедрять свою целевую схему подписи Шнорра в пользователя

277

Поскольку схема подписи Шнорра доказана, что безопасна в предположении дискретного логарифма [21], теорема 2 гарантирует, что Предлагаемая схема AKESSO обеспечивает безопасную аутентификацию пользователя на основе учетных данных в предположении дискретного логарифма.

[4] Ф. Бао, Р. Х. Дэн, «Защита конфиденциальности операций с цифровыми товарами», Труды Третьей Международной конференции по информационной и коммуникационной безопасности (ICICS ’01), Springer-Verlag, Лондон, Великобритания, стр.202-213. [5] Открытая группа, «Форум безопасности по единому входу», http: // www. opengroup.org/security/l2-sso.htm. [6] Г. Ван, Дж. Ю и К. Се, «Анализ безопасности механизма единого входа в систему для распределенных компьютерных сетей», IACR Cryptology ePrint Archive, Report 2012/107, http://eprint.iacr.org/ 2012/107. [7] W. B. Lee и C. C. Chang, «Идентификация пользователей и распределение ключей с сохранением анонимности для распределенных компьютерных сетей», Computer Systems Science and Engineering, vol. 15, вып. 4, стр.113-116, 2000. [8] Т.-С. Ву и Ч.-Л. Хсу, «Эффективная схема идентификации пользователей с распределением ключей, сохраняющая анонимность для распределенных компьютерных сетей», «Компьютеры и безопасность», том. 23, нет. 2, pp. 120-125, 2004. [9] Янг, С. Ван, Ф. Бао, Дж. Ван и Р. Х. Дэн, «Новая эффективная схема идентификации пользователей и распределения ключей, обеспечивающая повышенную безопасность», Компьютеры и безопасность , т. 23, нет. 8, pp. 697-704, 2004. [10] К. В. Мангипуди и Р. С. Катти, «Протокол безопасной идентификации и согласования ключей с анонимностью пользователя (sika)», Компьютеры и безопасность, том.25, нет. 6, pp. 420-425, 2006. [11] C.-L. Сюй и Ю.-Х. Чуанг, «Новая схема идентификации пользователей с распределением ключей, сохраняющая анонимность пользователей в распределенных компьютерных сетях», Inf. Sci., Т. 179, нет. 4, pp. 422-429, 2009. [12] C.-C. Чанг и Ч.-Й. Ли, «Безопасный механизм единой регистрации для распределенных компьютерных сетей», IEEE Transactions on Industrial Electronics, vol. 59, нет. 1, pp. 629-637, 2012. [13] C.P. Шнорр, «Эффективное создание подписи с помощью смарт-карт», J. Cryptology, vol. 4, вып.3, стр. 161-174, 1991. [14] С. Голдвассер, С. Микали и К. Ракофф, «Сложность знаний интерактивных проверочных систем», SIAM J. Computing, vol. 18, нет. 1, pp. 186-208, февраль 1989 г. [15] В. Мао, Современная криптография: теория и практика, Prentice Hall PTR, 2004. [16] Дж. Хан, Ю. Му, В. Сусило и Дж. Ян, «Общая конструкция динамического единого входа с надежной защитой», в Proc. of SecureComm’10, стр. 181–198, LNICS 50, Springer, 2010. [17] М. Беллар и П. Рогавей, «Аутентификация сущностей и распространение ключей», CRYPTO, стр.232-249, 1993. [18] C.P. Шнорр, «Эффективная идентификация и подписи для смарт-карт», CRYPTO, стр. 239-252, 1989. [19] М. Белларе и А. Паласио, «Схемы идентификации GQ и Шнорра: доказательства защиты от выдачи себя за другое лицо при активных и одновременных атаках», CRYPTO, стр. 162-177, 2002. [20] D . Pointcheval, J. Stern, «Доказательства безопасности для схем подписи», EUROCRYPT, pp. 387-398, 1996. [21] D. Pointcheval, J. Stern, «Аргументы безопасности для цифровых подписей и слепых подписей», J.Cryptology , т.13, № 3, стр. 361-369, 2000. [22] С. Голдвассер, С. Микали, Л. Рональд, «Парадоксальное» решение проблемы подписи (расширенное резюме) », FOCS, стр. 441-448, 1984. [23] С. Голдвассер, С. Микали и Р. Л. Ривест, «Схема цифровой подписи, защищенная от атак с адаптивным выбранным сообщением», SIAM J. Comput., Vol. 17, нет. 2, pp. 281-308, 1988.

Теорема 3. (Безопасная аутентификация поставщика услуг) В предлагаемом AKESSO, если есть злоумышленник A PPT, который имеет немаловажное преимущество Adv SSP A (AO), как указано в определении 4 , то схема подписи подписи, используемая поставщиками услуг, может быть подделана в рамках атак UF CM A, как это определено в Разделе IV.Доказательство: поскольку доказательство поставщика услуг генерируется непосредственно как нормальная подпись соответствующим поставщиком услуг, теорема 3 может быть формально доказана, как мы это сделали для случая (2) в теореме 1. Обратите внимание, что здесь нам не нужно обсуждать случай (1). ), как в теореме 1, поскольку каждый поставщик услуг должен зарегистрировать свою пару открытого / закрытого ключей. Из-за нехватки места полное доказательство опускается. Теорема 4. Согласно определению 6, предлагаемая схема AKESSO является безопасной при условии, что все цифровые подписи, используемые в схеме, экзистенциально неподдаются подделке против атак U F CM A, как указано в разделе IV.Доказательство: По теореме 1, теореме 2, теореме 3 и безопасности сеансового ключа, доказанной в [12], теорема 4 верна в соответствии с определением 6. VII. ВЫВОДЫ Большинство существующих схем единого входа страдают от различных проблем безопасности и уязвимы для различных атак. В этой статье мы впервые формализовали схему единой регистрации при обмене ключами с аутентификацией. В частности, мы официально определили безопасную аутентификацию как для пользователей, так и для поставщиков услуг, поскольку такая обработка еще не изучена [6]. Более того, была предложена схема SSO на основе механизма Шнорра, чтобы преодолеть недостатки схемы Чанга-Ли [12], но сохранить те же преимущества.В этой новой схеме, чтобы сохранить конфиденциальность создания учетных данных, T CP подписывает подпись Шнорра [18] [13] на идентификаторе пользователя; и для защиты конфиденциальности и надежности учетных данных пользователь использует свои учетные данные в качестве ключа подписи для подписи подписи Шнорра на хешированном сеансовом ключе. Фактически, механизм подписи Шнорра [18] [13] более эффективен, чем механизм RSA, который использовался схемой Чанга-Ли. Таким образом, предлагаемая схема снижает стоимость вычислений, повышает конфиденциальность и сохраняет надежность и конфиденциальность учетных данных.СПИСОК ЛИТЕРАТУРЫ [1] А. К. Уивер и М. В. Кондтри, «Распространение интернет-сервисов на периферию сети», IEEE Trans. Ind. Electron., Vol. 50, нет. 3, стр. 404-411, июнь 2003 г. [2] Л. Баролли и Ф. Кхафа, «JXTA-OVERLAY: P2P-платформа для распределенных, совместных и повсеместных вычислений», IEEE Trans. Ind. Electron., Vol. 58, нет. 6, pp. 2163-2172, Oct. 2010. [3] Л. Лэмпорт, «Парольная аутентификация при небезопасном обмене данными», Commun. ACM, т. 24, вып. 11, pp. 770-772, ноябрь 1981 г.

278

The World Crypto Network Podcast

Как безопасно обновить кошелек Wasabi v1.1.6 и Холодная карта v2.1.1

09 июля 2019 г. 8 минут

Этот выпуск кошелька Wasabi, как и предыдущий, состоит в основном из улучшений стабильности. Заметными улучшениями являются реализация полного рабочего процесса Coldcard PSBT, добавление обратного отсчета на вкладку CoinJoin, которая показывает следующее принудительное начало раунда, большинство исправлено. отработанные проблемы, «добавление новых опций на страницу настроек и гибкая консолидация изменений в CoinJoins. Большой выпуск Cold Card с поддержкой Multisig!» Новое меню в разделе: Настройки Multisig Wallets.Список всех импортированных кошельков M-of-N, которые уже настроены. Экспорт, импорт для создания с воздушным зазором Широкое изменение: значения расширенного пальца открытого ключа (XFP) обычно показывались с неправильным порядком байтов (байты менялись местами) и с префиксом 0x, чтобы указать, что они были числом. Фактически, они представляют собой байтовую строку и должны отображаться в сетевом порядке. Везде, где вы могли видеть, что ваше значение XFP было переключено, поэтому 0x0f056943 становится 4369050F (все заглавные буквы, без префикса 0x). V2.1.1: Новая функция: создание начальных слов из бросков кубиков D6: просто в разделе «Импортировать существующие броски кубиков» продолжайте нажимать 1–6 во время катания.Для 256-битного начального числа безопасности требуется не менее 99 роликов — sha256 (по всем роликам, как строка ascii) показаны нормальные исходные слова, поэтому вы можете записать их вместо роликов, также можно «смешивать» броски костей: после выбора Coldcard начальные слова и показывает их, нажмите 4, и вы можете затем сделать несколько бросков кубиков (столько или меньше, сколько хотите) и получить новый набор слов, который добавляет эти броски в качестве дополнительной энтропии. Экспорт скелетных кошельков для кошелька Wasabi https: //wasabiwallet.io/ для поддержки использования зазоров.Сводный файл (public.txt) был переработан, чтобы включить больше значений XPUB и предупреждение об использовании адресов, к которым ваш кошелек для мониторинга цепочки блоков может быть не готов. Когда кодовая фраза BIP39 передается через USB и утверждается, новый XFP отображается на экране для справки. v2.1.1: Поддержка кошелька Wasabi: удалить лишнюю информацию из файла скелета, изменить порядок байтов XFP, добавить поле версии. Использование с Electrum потребует наших обновленных изменений плагина. Если вы узнали что-то ценное, пожертвуйте пару сатов Макс в качестве благодарности: 3Fe6dcwhkLnMo7c2FrkYduR5xJgo38dTTS https: // tallyco.in / HillebrandMax Поддержите шоу, складывая саты на https://hodlhodl.com/join/ERCT Слушайте аудиоподкасты WCN: https: //itunes.apple.com/us/podcast/t …

достижений в области беспроводной связи — Колледж Васави …

Регистрация Сведения о регистрации: Регистрационный сбор должен быть оплачен ДД в пользу колледжа Васави . of Eng in eer in g »Важные даты, подлежащие оплате в Хайдарабаде.Подача статьи в полном объеме 30.01.12 Уведомление о принятии 09.02.12 Готовность к работе с камерой 16.02.12 и Категория регистрации Научный сотрудник Преподавательский состав из академической среды Дата конференции 03.03.12 Адрес для регистрации организатора корреспонденции Rs. 500 / — рупий. 750 / — Делегаты от промышленных предприятий и научно-исследовательских организаций Rs. 1,500 / — ВАСАВИ ИНЖЕНЕРНЫЙ КОЛЛЕДЖ Ибрагимбаг, Хайдарабад — 31. Тел .: 091-040-23146040 (Внешний: ECE) 091-040-23146055 (Внешний: ECE) Факс: 091-040-23146080 Консультативный комитет: Dr.М. Сатьям, IIIT, HYD, доктор В.У. Редди, HYD, доктор А.Д. Шарма, О.Ю., HYD Organiz in g Комитет: Главный патрон: Шри. П. Баладжи, генеральный директор VCE, Хайдарабад. Покровитель: д-р И.В. Рао, Пр in cipal, VCE, Хайдарабад. Председатель: д-р К. Джая Санкар, профессор . И HOD, ECE, VCE, Hyd Сопредседатель: д-р П.А. Губернатор в дхачарюлу, Pr of ., ECE, VCE, Hyd Conveners: Ms.R. Leelavathi, Asst. Пр из . (8143672172) г-жа К. Дипти, ассистент. Пр из . (

40306) Технический комитет: д-р П. Анант Радж, О.Ю., Хид д-р П. Чандрасекхар, О.Ю., Хид д-р Б.Н. Бхандари, JNTU, Hyd Pr

of . РБ Раджендра Прасад, ECE, VCE, Hyd, д-р NVKRao, профессор и руководитель, ECE, CBIT, Hyd Доктор Б. Хари Кумар, профессор и руководитель, ECE, MVSR, Hyd Dr. Kaleem Fathima, Pr of и руководитель, ECE, MJCET, Hyd Dr.Найим, профессор и руководитель ECE, DCET, Hyd Organiz в g Команда: факультет отдела ECE и студенческие координаторы в координаторах. Национальная конференция по достижениям в беспроводной связи (NCAWC-2012) 3 марта 2012 г. Организовано Департаментом of Electronics & Communication Eng in eer in g ВАСАВИ ИНЖЕНЕРНЫЙ КОЛЛЕДЖ Ибрагимбаг, Хайдарабад — 31.Тел .: 091-040-23146040 (Внешний: ECE) Факс: 091-040-23146080 Адрес электронной почты: NCAWC12@gmail.

НВК. Наружные сети водоснабжения и канализации

Проектирование систем водоснабжения

Проектирование систем канализации

Проектирование сетей НВК, НВК проект

НВК — это… Что такое НВК?

проект в категории Отопление/Вентиляция, 04.

Слаботочные сети

Проектирование слаботочных систем

Мы проектируем различные виды слаботочных систем

Состав проектной документации « СМ-проект

Стадия 1 — ПП. Предпроектные проработки (Эскизный проект)

Стадия 2 — ПД. Проектная документация

Стадия 3 — РД. Рабочая документация

Сети теплоснабжения, тепловые сети

Bitcoin Segwit может заблокировать доступ пользователей кошельков к их средствам

Вкратце

Уязвимость

Сопутствующий ущерб

Bitcoin Segwit могло заблокировать доступ пользователей кошелька к их средствам — Расшифровать

Уязвимость

Сопутствующий ущерб

(PDF) Криптография в Интернете вещей

Сети большого радиуса действия и сети с низким энергопотреблением для Интернета вещей

Аннотация

1. Введение

1.1. Связанные работы

1.1.1. IEEE802.15.4

1.1.2. Bluetooth / LE

1.1.3. IEEE 802.11 ah

1.1.4. Sigfox

1.1.5. DASH7

1.2. Заявление о цели

2. Обзор LoRa

2.1. Стек протоколов LoRa

2.2. Архитектура сети LoRa

3. Физический уровень LoRa

3.1. Обзор физического уровня

3.2. Параметры физического уровня

Таблица 1

3.3. Физический формат кадра

3.4. Оценка производительности

3.4.1. Чувствительность приемника

3.4.2. Покрытие сети

4. Протокол LoRaWAN

4.1. Компоненты сети LoRaWAN

4.2. Формат сообщения LoRaWAN

4.3. Настройка конечного устройства

4.4. Команды MAC LoRaWAN

5. Анализ LoRaWAN

5.1. Максимальная пропускная способность одного устройства и MTU

5.2. Общая емкость и нагрузка на канал

5.3. Оценка частоты конфликтов

5.4. Роль сетевого сервера

5.5. Роль шлюза

6. Выводы

[PDF] Защищенная схема единого входа в распределенных системах и сетях

The World Crypto Network Podcast

Как безопасно обновить кошелек Wasabi v1.1.6 и Холодная карта v2.1.1

достижений в области беспроводной связи — Колледж Васави …

40306) Технический комитет: д-р П. Анант Радж, О.Ю., Хид д-р П. Чандрасекхар, О.Ю., Хид д-р Б.Н. Бхандари, JNTU, Hyd Pr

Добавить комментарий Отменить ответ