Заявление о выдаче судебного приказа гпк: ГПК РФ Статья 124. Форма и содержание заявления о вынесении судебного приказа 

ГПК РФ Статья 124. Форма и содержание заявления о вынесении судебного приказа 

1. Заявление о вынесении судебного приказа подается в письменной форме.

2. В заявлении о вынесении судебного приказа должны быть указаны:

1) наименование суда, в который подается заявление;

2) наименование взыскателя, его место жительства или место нахождения;

КонсультантПлюс: примечание.

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

(см. текст в предыдущей редакции)

4) требование взыскателя и обстоятельства, на которых оно основано;

5) документы, подтверждающие обоснованность требования взыскателя;

6) перечень прилагаемых документов.

В случае истребования движимого имущества в заявлении должна быть указана стоимость этого имущества.

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

Открыть полный текст документа

 4-сон 03.02.2006. О некоторых вопросах, связанных с применением законодательства, регулирующего приказное производство

Новые требования к судебным приказам

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

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

Таким новшеством стали изменения, внесенные в ГПК РФ, касающиеся порядка подачи заявления о вынесении судебного приказа (СП). Не спорю, что приказной порядок судопроизводства менее затратен для взыскателей и судов, особенно, по временным параметрам.

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

Федеральным законом от 28.11.2018 г. № 451-ФЗ внесены изменения в ст. 124 ГПК РФ, согласно части 

Подпункт 3 п. 2 ст. 124 ГПК РФ, касающийся идентификаторов личности должника, изменен на основании Федерального закона от 28.11.2018 № 451-ФЗ и вступает в силу с момента начала деятельности апелляционных и кассационных судов — с 01 октября 2019 года согласно Постановлению Пленума Верховного Суда РФ от 12 сентября 2019 г. № 30 «О дне начала деятельности кассационных и апелляционных судов общей юрисдикции, Центрального окружного военного суда».

А вот где заявители должны взять эти сведения, никто не прописал и не подумал. Ни в одной норме закона не прописано об обязанности миграционных органов, ГИБДД, ИФНС, ПФР сообщать указанную информацию об идентификаторах гражданина третьим лицам. И взять эти идентификаторы личности совершенно неоткуда, поэтому процедура получения судебного приказа стала невозможной для заявителей с 01 октября 2019 года.

И почти на месяц суды получили отдых, не принимая заявления о вынесении судебных приказов, так как изменения в закон о приостановлении действия этих норм рассматривались законодателями все это время. В соответствии с пп. 3 п. 1 ст. 125 ГПК РФ несоблюдение требований к форме и содержанию СП является основанием для возвращения заявления о выдаче судебного приказа.

Хотя в нашем регионы суды раньше могли запросить сведения месте и дате рождения должника, его месте работы, если к заявлению о вынесении СП приложить ходатайство. Так как в главе 11 ГПК РФ, касающейся порядка выдачи судебного приказа, не содержится норм, позволяющих ходатайствовать перед судом о запросе необходимых для рассмотрения заявления требований, в силу п. 4 ст. 1 ГПК РФ, можно, по моему мнению, применить аналогию закона. Соответственно, нормы ГПК об исковом производстве в части, касающейся запросов суда, доказательств и ходатайств, могут применяться при рассмотрении судами заявлений о выдаче СП. Но не все суды согласны с этим, даже в нашем городе.

Законодателям все-таки пришлось приостановить применение данной нормы ГПК РФ об идентификаторах личности при вынесении судебного приказа. Федеральный закон от 17.10.2019 № 343-ФЗ «О внесении изменений в статью 21 Федерального закона «О внесении изменений в отдельные законодательные акты Российской Федерации» опубликован на официальном Интернет-портале.

Принятая и опубликованная редакция закона говорит об отсрочке на 180 дней с момента вступления в силу норм ФЗ № 451, а именно: положений пункта 42, подпункта «б» пункта 44, подпункта «б» пункта 47 статьи 10 и подпункта «а» пункта 4 статьи 16,

В заключении Правового управления СФ указано: «Установление нового срок вступления в силу вышеуказанных требований обусловлен тем, что в соответствии с действующей редакцией статьи 21 Федерального закона № 451-Ф предоставлении идентификатора в суд при обращении с исковым заявлением должно являться обязательным с дня начала деятельности кассационных судов общей юрисдикции и апелляционных судов общей юрисдикции (но не позднее 1 октября 2019 года), однако правового регулирования вопросов по истребованию вышеуказанных персональных данных (идентификаторов) ответчиков, должников в российском законодательстве отсутствует».

Так неужели при принятии ФЗ № 451 в первом, втором и третьем чтении, а также на момент внесения законопроекта на рассмотрение в Госдуму 21 июля 2019 года не было известно об отсутствии такого правового регулирования? Ведь инициаторам в лице И.А.Яровой, Г.П.Хованской и остальных инициативных депутатов до внесения своих законодательных инициатив необходимо было в первую очередь подумать о том, каким образом будут исполняться эти инициативы правоприменителями. Но складывается такое ощущение, что депутатам совершенно незачем беспокоиться по этому поводу. Как и по поводу того, что взыскатели почти целый месяц не могли подать заявления в суд о вынесении СП.

Но, тем не менее, отсрочка исполнения требований ФЗ № 451 об обязательном указании идентификаторов должника в заявлении о вынесении судебного приказа предоставлена законодателями до 30 марта 2020 года. До этого момента должны быть разработаны и вступить в силу нормы о правом регулировании способа получения этих сведений взыскателями.

Хотя чем было хуже прежнее правовое регулирование порядка выдачи судебных приказом, мне не очень понятно. Как и непонятно, что даст нововведение именно в гражданском судопроизводстве. Ведь работали же много лет и без особых проблем со старой редакцией ГПК РФ: подавали заявления, получали судебные приказы, направляли их судебным приставам-исполнителям. Почему бы не оставить в покое все то, что и так неплохо работает? Но сверху виднее, как нам жить внизу, на земле…

С уважением, Ильмира Носик.

Компания «Бурмистр.ру» разработала уникальную CRM-систему для УК и ТСЖ. Вся необходимая информация о сервисе здесь.

Обсудить статью и задать вопросы можно на нашем форуме или воспользуйтесь формой ниже.

Опубликован Федеральный закон «О внесении изменений в ФЗ от 01.04.2020 г. № 98-ФЗ»

24.12.2020

    Опубликован Федеральный закон «О внесении изменений в ФЗ от 01.04.2020 г. № 98-ФЗ» о переносе даты вступления в силу поправок в ГПК РФ и ФЗ «Об исполнительном производстве» относительно обязательного указания одного из идентификаторов должника (ИНН, СНИЛС, паспортные данные) до 01 января 2022 года.

      Законом № 451-ФЗ внесены изменения в ГПК РФ, в том числе, в ст. 124 и 131 ГПК, согласно которым при подаче в суд заявления о выдаче судебного приказа и искового заявления истец (в том числе, УО, РСО и т.п.) обязан указать также один из идентификаторов должника: страховой номер индивидуального лицевого счета, идентификационный номер налогоплательщика, серия и номер документа, удостоверяющего личность, основной государственный регистрационный номер индивидуального предпринимателя, серия и номер водительского удостоверения, серия и номер свидетельства о регистрации транспортного средства).

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

Подробно ознакомиться  с ФЗ «О внесении изменений в Градостроительный кодекс РФ и отдельные законодательные акты РФ» Вы можете, перейдя по ссылке: https://sozd.duma.gov.ru/bill/1026242-7

Заявление о выдаче судебного приказа – образец бланка 2021

Заявление

о выдаче судебного приказа

На основании ч. 6 ст. 229.5 АПК РФ прошу выдать второй экземпляр судебного приказа, заверенный гербовой печатью суда по делу № от , для предъявления его к исполнению.

Судебный приказ (понятие, основания и порядок вынесения, отмена).

Судебный приказ – судебное постановление, вынесенное судьей единолично на основании заявления о взыскании денежных сумм или об истребовании движимого имущества от должника по требованиям, предусмотренным статьей 122 Гражданско-процессуального кодекса РФ (ч. 1 ст. 121 ГПК РФ).

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

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

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

Согласно ст. 122 ГПК судебный приказ может быть выдан по требованиям, основанным на:

1. нотариально удостоверенной сделке;
2. сделке, совершенной в простой письменной форме;
3. протесте векселя в неплатеже, неакцепте и недатировании акцепта, совершенном нотариусом.

Судебный приказ может быть выдан также по требованиям о взыскании:

1. алиментов на несовершеннолетних детей, не связанным с установлением отцовства, оспариванием отцовства (материнства) или необходимостью привлечения других заинтересованных лиц;
2. с граждан недоимки по налогам, сборам и другим обязательным платежам;
3. начисленной, но не выплаченной работнику заработной платы;
4. расходов, произведенных в связи с розыском ответчика, или должника и его имущества, или ребенка, отобранного у должника по решению суда, а также расходов, связанных с хранением арестованного имущества, изъятого у должника,  и хранением имущества должника,  выселенного из занимаемого им жилого помещения, заявленным органом внутренних дел, налоговым органом, подразделением судебных приставов.

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

По правилам родовой подсудности заявление о выдаче судебного приказа должно быть подано мировому судье (п. 1 ч. 1 ст. 23 ГПК). По территориальной подсудности действуют общие правила, предусмотренные ст. 28-32 ГПК. Применение норм о территориальной подсудности возможно по каждому ее виду, однако с некоторыми изъятиями. Так, почти не будет использоваться норма об исключительной подсудности, поскольку в большей своей части она имеет отношение к делам о недвижимости. Напротив, широко применяются правила ст. 28 и 29 ГПК.

Заявление о вынесении судебного приказа согласно ст. 124 ГПК  подается в письменной форме.

В заявлении о вынесении судебного приказа должны быть указаны:

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

В случае истребования движимого имущества в заявлении должна быть указана стоимость этого имущества.

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

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

Судья отказывает в принятии заявления о вынесении судебного приказа по основаниям, предусмотренным статьями 134 и 135 ГПК РФ.

Кроме того, судья отказывает в принятии заявления в случае, если:

1. заявлено требование, не предусмотренное статьей 122 ГПК РФ;
2. место жительства или место нахождения должника находится вне пределов Российской Федерации;
3. не представлены документы, подтверждающие заявленное требование;
4. из заявления и представленных документов усматривается наличие спора о праве;
5. заявленное требование не оплачено государственной пошлиной.

Об отказе в принятии заявления о вынесении судебного приказа судья в течение трех дней со дня поступления заявления в суд выносит определение.

Судебный приказ по существу заявленного требования выносится в течение пяти дней со дня поступления заявления о вынесении судебного приказа в суд.

Судебный приказ выносится без судебного разбирательства и вызова сторон для заслушивания их объяснений.

Закон (ст. 127 ГПК) достаточно четко регламентирует содержание судебного приказа. Независимо от характера заявленного требования в нем указываются:

1. номер производства и дата вынесения приказа;
2. наименование суда, фамилия и инициалы судьи, вынесшего приказ;
3. наименование, место жительства или место нахождения взыскателя;
4. наименование, место жительства или место нахождения должника;
5. закон, на основании которого удовлетворено требование;
6. размер денежных сумм, подлежащих взысканию, или обозначение движимого имущества, подлежащего истребованию, с указанием его стоимости;
7. размер неустойки, если ее взыскание предусмотрено федеральным законом или договором, а также размер пеней, если таковые причитаются;
8. сумма государственной пошлины, подлежащая взысканию с должника в пользу взыскателя или в доход соответствующего бюджета;
9. реквизиты банковского счета взыскателя, на который должны быть перечислены средства, подлежащие взысканию, в случае, если обращение взыскания производится на средства бюджетов бюджетной системы Российской Федерации.

Часть 2 ст. 127 ГПК предусматривает особенности содержания судебного приказа о взыскании алиментов, хотя такие особенности могут быть выделены и по другим требованиям.

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

Судья высылает копию судебного приказа должнику, который в течение десяти дней со дня получения приказа имеет право представить возражения относительно его исполнения (ст. 128 ГПК РФ).

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

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

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

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

Судебный приказ или упрощённое производство: Видео

Статья 125.3. Подача заявления. Заявление о выдаче судебного приказа подается в суд по общим правилам подсудности.

Заявление и приложенные к нему документы представляются вместе с копиями по числу должников.
Комментарий к статье 125.3
1. В статье сформулировано общее правило подсудности требований о выдаче судебного приказа. Приказ должен выдаваться судом по месту жительства ответчика, а если ответчиком является юридическое лицо — по месту нахождения органа или имущества юридического лица. В тех случаях, когда истребуется имущество, заявление может быть подано и по месту нахождения имущества.
2. Как быть в том случае, если место жительства ответчика неизвестно, и может ли к приказному производству применяться в этом случае норма, согласно которой иск может быть предъявлен по месту нахождения его имущества или по последнему известному месту его жительства. Вопрос не такой простой, как кажется на первый взгляд. По ГПК 1923 г. такое правило допускалось, но для приказного производства того времени не требовалось извещения ответчика по делу.
3. Извещение должника о заявленном кредитором в суд требовании о выдаче судебного приказа имеет более важное и принципиальное значение, нежели извещение ответчика о заявленном иске. Ответчик в исковом производстве в любом положении дела может обжаловать постановление суда первой инстанции в суд второй инстанции.
Ответчик же в приказном производстве фактически лишен возможности на основании своей жалобы поставить вопрос о проверке по существу перед судом второй инстанции постановления судьи о выдаче судебного приказа (см. ст. 125.10). Поэтому представляется более правильным в случае неизвестности места жительства ответчика рассматривать требования кредитора как исковые.
4. Приказное производство не исключает множественности лиц на ответной стороне, поэтому заявление в суд и приложенные к нему документы согласно ч. 2 комментируемой статьи представляются вместе с копиями по числу ответчиков. Документ, на основании которого выдается судебный приказ, должен быть в подлиннике.

Topps Garbage Pail Kids Предметы коллекционирования Blockchain можно найти в Target и Walmart — Blockchain Bitcoin News

Популярная компания по производству карточек Topps только что запустила серию «2021 Garbage Pail Kids Food Fight», и наборы торговых карточек продаются в магазинах Target и Walmart. Мало того, что серия Garbage Pail Kids (GPK) предоставит людям коллекционные картонные торговые карты, Topps также вставила редкие кодовые карты на основе блокчейна, которые можно обменять на эксклюзивные коллекционные невзаимозаменяемые токены GPK (NFT) в блокчейне Wax.

Блокчейн и GPK

С восьмидесятых годов Garbage Pail Kids (GPK) является популярной серией коллекционных карточек, созданной компанией Topps. Фирма Topps была основана в 1938 году и десятилетиями создавала коллекционные открытки для множества видов спорта и хобби. Topps также владеет жевательной резинкой Bazooka, конфетами Ring Pop, Push Pop и Baby Bottle Pop.

В последнее время карты GPK снова стали популярными, после того, как в восьмидесятые годы были заголовками газет. Пачки первой серии оригиналов GPK 1985 года, особенно серии глянцевых карточек, могут принести тысячи долларов. Между тем, с момента рождения Биткойна технология блокчейна изменила не только финансы, но и другие отрасли, такие как искусство и предметы коллекционирования. В прошлом году Топпс объединил усилия с восковой фигурой.io (блокчейн Wax) и выпустила первые итерации цифровых коллекционных предметов GPK.

«Технология блокчейн позволяет сборщикам выйти на рынок, где они могут покупать цифровые торговые карточки Garbage Pail Kids», — отмечает сайт Topps под названием topps.wdny.io. «[Коллекционеры могут] предлагать и совершать сделки, демонстрировать свой инвентарь в социальных сетях и искать списки желаний других трейдеров».

Topps запускает серию по борьбе с едой для детей в мусорных ведрах 2021 года с шансами на выигрыш вощеного блокчейна GPK NFT

Блокчейн Wax позволяет людям создавать, покупать, продавать и обменивать виртуальные NFT и физические предметы.С 2017 года сеть Wax утверждает, что она способствовала обмену более чем 100 миллионами цифровых предметов. На этой неделе Topps выпускает серию «2021 Topps Garbage Pail Kids Food Fight», которая будет продаваться, как и любые другие ежегодные наборы GPK в Targets и Walmarts.

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

«24 февраля 2021 года Topps выпускает физические пакеты в Walmart и Target. 25 февраля 2021 года цифровая версия будет выпущена на блокчейне Wax », — сказал Топпс во время объявления. «Коллекционеры физических карт могут также получить карту с эксклюзивным кодом погашения в физических пакетах, которые будут награждать эксклюзивными цифровыми коллекционными предметами на блокчейне Wax. Дополнительные цифровые наборы для эксклюзивных имен персонажей «b» можно будет приобрести непосредственно на Wax во время Wintercon 2021 от Topps Digital, который начнется 25 февраля.«Поклонники ГПК могут ознакомиться с картами на сайте wax.io.

Topps и хост Topps Digicast, Марк Сил также сказал:

Когда я пришел в Topps два года назад, мы с нашим вице-президентом Тобином Лентом подробно обсудили блокчейн и его значение для цифровых предметов коллекционирования. Мы оба, как и многие другие в Topps, видим удивительный потенциал блокчейна.

Незаменяемые токены и предметы коллекционирования на основе блокчейнов были в моде с 2020 года, и на торговых площадках NFT были совершены сделки на миллионы долларов.Совсем недавно люди обменивали баскетбольные карточки на основе NFT под названием «NBA Top Shots». В понедельник 27 000 уникальных людей приобрели карточки NBA Top Shots, и объем продаж превысил 32 миллиона долларов.

Что вы думаете о Topps и блокчейн-команде Wax, выпускающей цифровые карты GPK в физических упаковках в избранных магазинах Target и Walmart? Сообщите нам, что вы думаете по этому поводу, в разделе комментариев ниже.

Теги в этой истории

Кредиты изображений : Shutterstock, Pixabay, Wiki Commons, Topps, Garbage Pail Kids, GPK 2021, Wax Blockchain,

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

509 Превышен предел пропускной способности

Forms & Downloads — Town of Cortlandt, NY

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

Schlam Stone & Dolan LLP Суд аннулирует залоговое право удержания из-за преувеличенного иска

Сообщение: 14 мая 2020 г.

23 апреля 2020 года судья Масли из коммерческого отдела округа Нью-Йорк вынес решение по делу GPK 31-19 LLC v.L&L Constr. Dev. Inc. , 2020 NY Slip Op. 31046 (U), аннулирование залогового удержания, поскольку оно было чрезмерным, объясняя:

Закон о залоговом удержании № 39 гласит, что умышленно завышенная сумма залога является ничтожной. Элементами основания иска для умышленного преувеличения залогового права являются: (i) было предъявлено право удержания; (ii) сумма залога была завышена по сравнению с основным требованием; и (iii) это преувеличение является преднамеренным, а не результатом честной ошибки. Ответчики также отметили, что:

Претензия в соответствии с Законом о залоге 39-а подлежит упрощенному рассмотрению, если доказательства относительно того, умышленно ли преувеличил право залогодатель, является убедительным.Такое бремя обязательно включает доказательство надежности правообладателя. Соответственно, вопрос о преднамеренном или мошенническом преувеличении обычно решается в ходе судебного разбирательства по делу о взыскании права выкупа, а не на основании суммарного решения.

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

Ответчики не только не представляют доказательств того, что право удержания Подрядчика не является преднамеренно преувеличенным, но вместо этого признает факты, которые требуют отказа в их ходатайстве для отклонения иска о преднамеренном преувеличении. В пункте 7 своих показаний под присягой Сянбо заявляет, что самая большая часть залогового удержания механика Подрядчика в размере 315 039,14 долларов (Уведомление L&L о залоге механика от 16.02.17) представляет собой то, что Подрядчик прогнозировал как потерянную прибыль от Проекта, 10% от цены Контракта, примерно 220 000 долларов.Упущенная выгода не может быть возвращена механику под залог. По той же причине должно быть удовлетворено требование Владельца и Вестчестера об аннулировании залогового права и освобождении залога от залога.

Это не случай простой неточности или честной ошибки при установлении суммы залога. Скорее, ответчики признают, что Подрядчик получил 220 000 долларов от Заказчика для земляных работ и строительства фундамента, однако ответчики не могут доказать, что Подрядчик израсходовал какие-либо из этих средств на платежи субподрядчикам или материальным работникам для завершения этой Работы.Суд вынужден удовлетворить ходатайство Владельца и Вестчестера об аннулировании залогового права в соответствии с § 39 Закона о залоговом удержании и постановлении об освобождении залога от залога.

(внутренние цитаты и цитаты опущены).

Мы часто рассматриваем споры по строительным контрактам и продаже или аренде коммерческой недвижимости. Свяжитесь с партнером Schlam Stone & Dolan Джоном Лундином по адресу [email protected], если вы участвуете в споре, касающемся сделки с коммерческой недвижимостью.

Щелкните здесь, чтобы подписаться на тот или иной блог Schlam Stone & Dolan.

Основанная на блокчейне структура репутации для сохранения конфиденциальности для систем коллективного контроля

Аннотация

Совместное зондирование набирает популярность как метод сбора и обмена информацией из распределенных локальных сред с использованием мобильных устройств с богатыми датчиками. В настоящее время широко используется ряд совместных приложений распознавания, таких как сервисные приложения на основе определения местоположения (например,г., Waze навигация). Обычно эти совместные приложения собирают огромные объемы сенсорных данных, содержащих личную информацию, включая идентификационные данные пользователя и текущее местоположение. Из-за высокой чувствительности этой информации приложениям совместного распознавания требуется механизм сохранения конфиденциальности, такой как анонимность, для защиты и защиты личных данных пользователей. Однако использование анонимных идентификаторов для обнаружения источников оказывается затруднительным при оценке достоверности данных. С этой точки зрения, успешное приложение для совместного распознавания должно быть спроектировано с учетом двух проблем: (1) конфиденциальность пользователя и (2) надежность данных.На сегодняшний день для решения обеих этих проблем был предложен ряд методов сохранения репутации, сохраняющих конфиденциальность, но протоколы содержат несколько критических недостатков или непрактичны с точки зрения реализации. В частности, нет работы, которая могла бы прозрачно управлять значениями репутации пользователей, одновременно отслеживая анонимные личности. В этой работе мы представляем основанную на блокчейне структуру репутации, сохраняющую конфиденциальность, под названием BPRF для прозрачного управления значениями репутации пользователей и обеспечения прозрачного процесса отслеживания анонимных идентификаторов.Оценка производительности и анализ безопасности показывают, что наше решение практично и способно удовлетворить два требования: конфиденциальность пользователей и надежность данных.

Введение

В связи со стремительным развитием технологий мобильной связи в последние годы мобильные устройства с большим количеством датчиков, такие как смартфоны и планшетные ПК, стали обычным продолжением повседневной жизни. Используя эту мобильную среду, интерактивные системы распознавания привлекают большое внимание [1].При совместном восприятии распределенные пользователи с мобильными устройствами собирают данные из окружающей среды и загружают их на сервер приложений с помощью технологий мобильной связи (например, 4G / 5G или Wi-Fi). Сервер приложений агрегирует загруженные данные от нескольких пользователей, а затем определяет значимую информацию, анализируя агрегированные данные. Анализируемые результаты предоставляются пользователям, которые зарегистрировались в соответствующих сервисах коллективного зондирования. показывает базовую архитектуру системы распознавания с участием участников.

Система участия.

Архитектура совместного распознавания может применяться к множеству приложений, таких как службы определения местоположения [2] (например, навигация Waze) и службы определения местоположения [3] (например, TrackR).

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

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

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

С этой точки зрения успешное приложение совместного распознавания должно удовлетворять двум требованиям: (1) конфиденциальность пользователя и (2) надежность данных. Однако одновременное выполнение этих двух требований — непростая задача. Конфиденциальность пользователей часто обеспечивается устранением связей между последовательными действиями пользователя (например,g., последовательное получение информации от одного пользователя), но такие ссылки обычно требуются для оценки достоверности данных. Например, в системе партисипаторного распознавания на основе псевдонимов пользователь может иметь набор псевдонимов и переключаться между ними в каждом сеансе, чтобы затруднить связывание своих вкладов. Из-за такого неустойчивого поведения система коллективного распознавания практически неспособна отследить отдельного пользователя, анализируя предоставленные данные в системе. (В этой статье «отслеживание» означает выяснение настоящей личности анонимного пользователя).С другой стороны, использование псевдонима затрудняет влияние или манипулирование репутацией пользователя для любого пользователя, поскольку поведение пользователя обычно отслеживается с помощью уникального идентификатора, а не нескольких идентификаторов (то есть псевдонимов). Как правило, управление ценностями репутации используется для проверки достоверности данных. Тем не менее, несмотря на то, что надежность данных не полностью зависит от значений репутации пользователей, существует общая корреляция между высокой вероятностью достоверности сообщаемых данных и высокими значениями репутации пользователей.

Вклады

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

В BPRF алгоритм групповой подписи и алгоритм частично слепой подписи используются для защиты частной информации пользователя. AS отвечает за регистрацию пользователей, которые хотят присоединиться к приложениям совместного распознавания, предлагаемым им самим. Во время регистрации всем пользователям назначается уровень репутации по умолчанию AS и они получают соответствующие ключи членов группы. После регистрации пользователь может передать информацию обнаружения со значением групповой подписи в приложение для участия AS . Успешный вклад в приложение AS предлагает участвующему пользователю жетон вознаграждения, который подписан AS с помощью алгоритма частично слепой подписи.Токены, выпущенные AS , затем передаются в блокчейн (то есть смарт-контракт), отвечающий за управление значениями репутации пользователей. Во время каждого экземпляра обновления репутации AS присваивает каждому пользователю новый уровень репутации, который определяется значением репутации каждого пользователя. Количество уровней репутации зависит от политики конфиденциальности AS . Если возникает спор относительно поддельной информации, потенциально отправленной злоумышленником, TS может отследить действие до пользователя, сотрудничая с сервером приложений.Таким образом, этот документ вносит следующие вклады:

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

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

• Путем вставки узнаваемой информации, такой как этот уровень репутации, для вознаграждения токенов, выпущенных AS , токены становятся непередаваемыми другим пользователям с разными уровнями репутации.

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

Сопутствующие работы и строительные блоки

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

Некоторые исследования были предложены в [4–12] для обеспечения сохраняющих конфиденциальность методов репутации, но эти подходы имеют несколько недостатков.

В [4] и [5] сервер приложений, который управляет значениями репутации пользователей, также может отслеживать поведение пользователей. Таким образом, эти исследования не защищены от честной, но любопытной модели сервера, в которой предполагается, что сервер всегда следует протоколу, но может попытаться собрать неавторизованную (или частную) информацию из журналов протокола за пределами разрешенных параметров.В [6] злоумышленников нельзя отследить или исключить из анонимных групп, поскольку система обеспечивает анонимность, которую невозможно отследить. Другими словами, никто не может раскрыть настоящую личность злоумышленника. Точно так же исследование в [7] не может обнаружить или отследить ненормальное использование значения репутации. Например, если злонамеренный пользователь с низким значением репутации будет злоупотреблять высоким значением репутации, доступным в сотрудничестве с сговорившимися пользователями, ненормальное поведение не будет обнаружено или помечено сервером приложений.

В то время как исследования [4–7] не могут полностью рассмотреть репутацию, сохраняющую конфиденциальность, работы [8–12] также недостаточны для применения в различных прикладных средах совместного распознавания. Чжай и др. . предложил анонимную систему репутации, основанную на существовании множества псевдонимов, генерируемых совместной работой на нескольких серверах, а не на одном сервере [8]. Однако этот подход неэффективен для чувствительных ко времени функций приложений совместного распознавания, таких как чувствительная ко времени система обмена информацией Waze, из-за продолжительности времени, необходимого для генерации одного псевдонима — около 2000 секунд при 100 000 участвующих пользователей.Это недопустимая задержка, учитывая природу чувствительных ко времени приложений. То есть, если бы эту работу применили к Waze, пользователю пришлось бы ждать 2000 секунд, чтобы получить новый псевдоним, чтобы передать новое событие трафика обратно на сервер Waze. В работе [8] предлагается опция параллельной работы для сокращения времени, необходимого для генерации нового псевдонима. Однако, поскольку существует компромисс между опцией параллельной работы и конфиденциальностью, опция параллельной работы по-прежнему ограничена. Аналогичным образом, исследования [9–12] применимы только к системам онлайн-покупок, потому что пользователям, участвующим в этих исследованиях, разрешается делиться некоторой информацией, только если у них есть предыдущая история покупок.Наконец, насколько нам известно, важно отметить, что не существует работ, которые прозрачно управляют ценностями репутации пользователей. Прозрачное управление процессом управления репутацией и процессом отслеживания уместно для повышения надежности управления репутацией с сохранением конфиденциальности.

Стандартные блоки

Групповая подпись

В алгоритмах групповой подписи набор пользователей назначается одной группе. Затем пользователь, включенный в группу, подписывает сообщение анонимно, не раскрывая свою личность, используя групповой идентификатор [13].В общем, алгоритмы групповой подписи должны обеспечивать контролируемую анонимность, чтобы справиться с потенциальным злоупотреблением функциями анонимности [14, 15]. Например, менеджер группы, который управляет параметрами алгоритмов групповой подписи, может отслеживать подписавшего по его собственному определенному значению групповой подписи, если есть спор, связанный с подписавшим. Функции, требуемые подписью управляемой группы, описаны ниже.

• GS.Initialize_By_Server ( k ₁ ) → GPK , GTK , GIK , GLK : с предварительно заданным параметром безопасности k

  эта функция выводит GPK , GTK , GIK и GLK , которые являются открытым ключом группы, ключом отслеживания группы, ключом выдачи группы и ключом групповой связи соответственно.

• GS.Initialize_By_User ( k ₂ ) → UPK , USK : со входом k ₂ (предварительно определенный параметр безопасности) эта функция выводит 16 UPK 90 USK , которые являются открытым и закрытым ключами пользователя соответственно.

• GS.Join (UserJoin ( GPK , ID , USK ), выпуск ( GPK , GIK , ID , UPK )) → : GM 9016 алгоритмы, UserJoin ( GPK , ID , USK ) (выполняется зарегистрированным пользователем) и Issue ( GPK , GIK , ID , UPK ) (выполняется издатель ключа члена группы), взаимодействуют для вывода ключа члена группы GMK , который хранится и управляется только на стороне пользователя.( ID - идентификатор зарегистрированного пользователя).

• GS.Sig (GPK, GMK, m) → σGMKGS (m): при вводе GPK , GMK и сообщении m эта функция выводит групповую подпись σGMKGS (m)

• GS.Ver (ГПК, σГМКГС (м), м) → 1 или 0 : на входе GPK , σGMKGS (m) и m эта функция выводит 1 (действительный) или 0 (недействительный).

• GS.Trace (ГПК, ГТК, σГМКГС (м), м) → УПК, τ : Со входом GPK , GTK , σ _GMK ( м ) и м , эта функция выводит открытый ключ подписывающей стороны ( UPK ) и доказательство τ .

• GS.Судья (ГПК, УПК, σГМКГС (м), м, τ) → 1 или 0: При вводе GPK , UPK , σGMKGS (m), m и τ эта функция выводит 1 (это означает, что владелец UPK генерирует σGMKGS (m)) или 0.

• GS. Link (ГПК, ГЛК, σGMKGS (м), ∑m) → 1 или 0: При вводе GPK , GLK , ∑σGMKGS (m) и ∑ m эта функция выводит 1, если существует более двух подписей, созданных одним пользователем и связанных с одним и тем же сообщением.В противном случае он выводит 0. (∑σGMKGS (m) и ∑ m - это набор значений групповой подписи и набор сообщений, соответственно).

• GS.Revoke ( GPK , GIK , Revo_List ) → GPK ^новый , Revo_Info : со списком 167 GIK , со списком Revo_List ), эта функция выводит открытый ключ новой группы ( GPK ^новый ) и информацию об отзыве ( Revo_Info ).

• GS.Update ( GPK , GPK ^новый , GMK , Revo_Info ) → GMK ^новый

  GP7

  : на входе

  ^новый , GMK и Revo_Info , эта функция выводит новый ключ члена группы ( GMK ^новый ), если U не указан Revo_Info .

Функции и термины, определенные в этом разделе, были использованы для разработки предлагаемой структуры. BPRF может принимать любые алгоритмы групповой подписи, обеспечивающие вышеописанные функции. Например, групповая подпись [14] может применяться к BPRF .

Частично слепая подпись

В работе [16] вводится концепция «ограничительной слепой подписи», с помощью которой проверяющие стороны могут получить некоторую идентифицирующую информацию для аутентификации.ABE et al. в качестве альтернативы предложен метод, называемый «частично слепая подпись», который позволяет подписывающей стороне включать произвольные общедоступные данные в слепую подпись [17]. Описанные далее функции являются основными функциями, обеспечиваемыми алгоритмом частично слепой подписи:

• PB.Initialize ( k ₃ ) → PPK , PSK : со входом k ₃ ( предварительно определенный параметр безопасности), эта функция выводит открытый ключ ( PPK ) и соответствующий ключ подписи ( PSK ) для частично слепой подписи.

• PB.Info (common_information) → Info: При вводе common_information эта функция выводит Info .

• PB. Слепой (PPK, rand, m) → слепой _m : с вводом PPK , случайным значением ( rand ) и сообщением m (например, идентификатор ), эта функция выводит скрытое сообщение слепой _m .

• ПБ.Sig (PPK, PSK, шторка _м , информация) → σPSKPB (шторка, информация): со входом PPK , PSK , информация и шторка _m , эта функция выводит подпись , σPSKPB (слепой, Инфо), на Инфо и слепой _м .

• PB.Unblind (rand, σPSKPB (blindm, Info)) → σPSKPB (m, Info): при вводе rand и σPBPB (blindm, Info) эта функция выводит подпись, σPSKPB (m, Info) , на м и Информация .

• PB.Ver (PPK, σPSKPB (m), m) → 1 или 0: при вводе PPK , σPSKPB (m) и m эта функция выводит 1 (действительный) или 0 (недействительный).

Функции и термины, определенные в этом разделе, были использованы для разработки предлагаемой структуры.

BPRF может использовать любые алгоритмы частично слепой подписи, обеспечивающие вышеописанные функции. Например, частично слепая подпись [17] может применяться к BPRF .

Блокчейн

Блокчейн - это распределенный реестр, представленный протоколом Биткойн в 2008 году [18], который прозрачно управляется одноранговой сетью. Блокчейн как безопасная и децентрализованная платформа широко используется для приложений, которым требуется прозрачное и неизменное управление данными без централизованного управления.

В Ethereum [19] смарт-контракты определены на высокоуровневом языке, похожем на JavaScript, который называется Solidity (https: //solidity.readthedocs.io / en / v0.5.11 /) Смарт-контракт, формализованный в исходном коде, может выполняться на узлах Ethereum без простоев, централизации или стороннего вмешательства. Как правило, смарт-контракты используются для реализации полезных приложений, предоставляемых блокчейном. Например, блокчейн со смарт-контрактами может предоставлять услугу по сбору средств, которая автоматически возмещает взносы, если определенная сумма не будет собрана в течение заданного периода времени. Помимо Ethereum, другие системы блокчейнов, такие как Hyperledger [20] и EOS [21], также определяют свои собственные системы для смарт-контрактов.

Мотивация и архитектура

В этом разделе представлены мотивирующий сценарий и архитектура предлагаемой структуры, BPRF .

Мотивация

BPRF мотивирован сервисами коллективного распознавания, такими как Waze. На рис. И показано мотивирующее приложение, рассмотренное для этого исследования, которое также является приложением, которое может поддерживаться этой предлагаемой структурой.

Система обмена событиями с использованием реальных данных.

Система обмена событиями с использованием анонимных идентификаторов.

In, автомобили A, B и C передают отчеты о близлежащих дорожных условиях, таких как автомобильные аварии или обновления строительной площадки, на номер AS . Согласно отчетам, AS сообщает о дорожных происшествиях. Другим транспортным средствам разрешается давать положительные или отрицательные отзывы об опубликованных событиях, когда они проезжают через районы, на которые, как сообщается, были нанесены опубликованные события. Как правило, все транспортные средства, передающие отчеты или обратную связь, должны делать это с помощью уникального индивидуального идентификатора, специально для процессов обработки сообщений / отзывов, таких как аутентификация сообщения или идентификация поддельной информации.Эти уникальные идентификаторы также используются для оценки репутации пользователей, которые внесли свой вклад в систему коллективного зондирования.

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

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

Архитектура BPRF

Предлагаемая структура BPRF состоит из потенциально большого количества пользователей, которые представляют пользователя ( U ), небольшое количество серверов приложений ( AS ), сервер трассировки ( TS ) и цепочка блоков.На практике, хотя каждый сервер приложений имеет свои собственные приложения, независимые от приложений, предоставляемых другими серверами приложений, пользователь может подписаться на несколько приложений, если он желает подписаться на различные услуги. BPRF позволяет пользователям анонимно загружать отчеты или сообщения обратной связи на AS . Однако при обнаружении фальшивых отчетов или сообщений обратной связи злоумышленник может быть отслежен благодаря сотрудничеству AS и TS . Блокчейн также используется для прозрачного управления ценностями репутации и отслеживания информации о пользователях.показана архитектура БПРФ .

Архитектура БНРФ .

Модель противника и предположения

Хотя честный объект в BPRF (сервер или пользователь) следует протоколу BPRF , все еще есть недобросовестные пользователи или серверы, которые не следуют указанному протоколу BPRF .

На стороне сервера ( AS или TS ) мы рассматриваем честную, но любопытную модель, в которой предполагается, что сервер всегда следует протоколу, но может попытаться получить информацию из стенограммы протокола сверх того, что предназначены для совместного использования [22].Например, если нет никаких доказательств того, что атака пытается получить личную информацию пользователя, честный, но любопытный сервер может использовать личную информацию пользователя, которая была получена в результате несанкционированного мониторинга пользователей без согласия пользователя. Кроме того, сервер может попытаться изменить значения репутации конкретных пользователей, присвоив каждому уникальное значение репутации, чтобы сервер отслеживал их, связывая вместе измененные значения репутации. Однако некоторые функции, такие как регистрация пользователя и процесс выдачи ключей, считаются выполненными честно, поскольку эти функции необходимы для AS и TS для предоставления клиентам их собственных услуг.

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

Мы предполагаем, что каждый объект имеет свой собственный открытый ключ и соответствующий закрытый ключ, который был сертифицирован сертифицированным центром (CA). Предполагается, что пользователи и приложения связаны анонимными каналами связи (например, Tor [23] или устойчивыми к анализу трафика сетями, такими как Dissent [24] и Vuvuzela [25]). Пользователи также могут быть подключены к серверам приложений через виртуальную частную сеть (VPN) для эффективного взаимодействия. Мы предполагаем, что AS и TS не вступают в сговор, и что предполагается, что большинство пользователей ведут себя честно.

Требования

Требования BPRF можно разделить на три категории следующим образом:

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

• Анонимность: мы определяем три типа анонимности: слабую, полусильную и сильную.Если достигается слабая анонимность, конфиденциальная информация пользователя ограничивается только третьими сторонами. Слабая анонимность позволяет одному серверу, например серверу приложений или серверу отслеживания, отслеживать анонимных пользователей. Анонимность является полусильной, когда анонимные пользователи отслеживаются, только если взаимодействуют более двух серверов. Чтобы уточнить, если достигается полусильная анонимность, анонимные пользователи не могут быть отслежены ни одним сервером, ни третьей стороной. Наконец, сильная анонимность достигается, когда нет абсолютно никаких лиц, которые могут отслеживать анонимных пользователей.

• Несвязанность: никакие объекты не должны иметь возможность связывать вместе сообщения отчета / обратной связи пользователя, если эти сообщения действительны. Значения репутации также не следует использовать для привязки сущности к определенному событию или событиям.

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

Управление репутацией: репутация пользователей должна управляться точно, прозрачно и периодически обновляться.

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

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

• Обновление: значения репутации следует периодически обновлять.

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

Дизайн BPRF

Обзор

BPRF состоит из шести процессов: 1) инициализация, 2) регистрация, 3) отчет / обратная связь, 4) обновление репутации, 5) отзыв и 6) отслеживание.Обозначения, используемые в BPRF , поясняются в.

Таблица 1

Обозначения.

может выбрать алгоритм групповой инициализации. создавать и управлять ключом отслеживания группы, ключом выдачи группы и ключом групповой связи, соответственно, используемыми для отслеживания реальных идентификационных данных злоумышленников, выдачи ключа члена группы для каждого пользователя и связывания групповых подписей.После инициализации параметров для выбранного алгоритма групповой подписи TS генерирует набор открытых ключей группы ( GPK ), ключей отслеживания группы ( GTK ), ключей выдачи групп ( GIK ) и ключей групповой связи ( ГЛК ). Затем TS и AS аутентифицируют друг друга. Если аутентификация прошла успешно, AS получает все GPK s, GIK s и GLK s от TS . Каждый кортеж из GPK , GIK и GLK сопоставлен с определенной группой репутации, представляющей определенный уровень репутации i ( RL _i ).Например, если AS имеет три уровня репутации: низкий, средний и высокий, каждый кортеж из GPK , GIK и GLK назначается всем трем уровням репутации.

Во время регистрации пользователь U _x регистрируется в AS для услуг подписки, предоставляемых AS . Затем пользователю назначается группа репутации по умолчанию, представляющая уровень репутации, и создается соответствующий ключ члена группы ( GMK _x ) посредством сотрудничества с AS .

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

Во время обновления репутации каждый пользователь, получивший Reward_Token s, передает все токены в блокчейн, то есть в смарт-контракт AS , который реализует политику управления репутацией для AS .Смарт-контракт обновляет значения репутации для всех пользователей в соответствии с политикой управления репутацией AS после проверки токенов вознаграждения. Благодаря обновленным значениям репутации, хранящимся в блокчейне, AS может обновлять уровни репутации пользователей. AS затем обновляет общедоступные параметры для уровней репутации (т. Е. Групп репутации), чтобы учитывать изменения членства, такие как добавление или удаление члена группы. Обновленная информация также передается всем пользователям.Продолжительность периода обновления репутации отличается от приложения к приложению и составляет от нескольких минут до нескольких часов или даже дней.

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

Каждый раз, когда AS обнаруживает поддельное сообщение, которое может негативно повлиять на надежность услуг AS , выполняется отслеживание рассматриваемого сообщения.В этом процессе подлинная личность отправителя поддельного сообщения отслеживается посредством сотрудничества между AS и TS , а затем значение репутации отправителя поддельного сообщения уменьшается в соответствии с политикой управления репутацией AS . показывает обзор BPRF .

Инициализация

TS выбирает алгоритм групповой подписи, который может отдельно создавать и управлять ключом отслеживания группы, ключом выдачи группы и ключом связи группы. AS и TS аутентифицируют друг друга с помощью инфраструктуры открытого ключа (PKI). AS устанавливает количество уровней репутации ( N _RL ), которое предварительно определено в его собственной политике репутации. AS запрашивает TS для создания N _RL кортежей из GPK , GTK , GIK и GLK для собственных услуг. Затем TS генерирует кортежи N _RL , используя GS.Initialize_By_Server ( k ₁ ), где k ₁ - предварительно определенный параметр безопасности. В то время как GTK хранятся в TS , GIK s и GLK s передаются на AS через защищенный канал, такой как канал безопасности транспортного уровня (TLS). Затем публично объявляется GPK s. Кроме того, пользователь ( U _x ) создает пару открытых ключей ( UPK _x ) и закрытый ключ ( USK _x ) через GS.Initialize_By_Server ( k ₂ ), где k ₂ - предварительно определенный параметр безопасности.

Чтобы предоставить пользователям скрытый токен, AS инициализирует открытый ключ ( PPK _AS ) и ключ подписи ( PSK _AS ) через PB. k ₃ ) после выбора алгоритма частично слепой подписи. ( k ₃ - предварительно определенный параметр безопасности).

Регистрация

Во время регистрации U _x и AS аутентифицируют друг друга с помощью PKI. AS затем назначает пользователю уровень репутации по умолчанию (например, средний уровень репутации), который определяется его собственной политикой репутации.

Затем пользователь и AS выполняют регистрацию. Другими словами, UserJoin (GPKRLi, IDx, USKx) и Issue (GPKRLi, GIKRLi, IDx, UPKx) интерактивно выполняются U _x и AS . ID _x - это идентификатор U _x , а GPKRLi и GIKRLi, соответственно, открытый ключ группы и ключ выдачи группы для уровня репутации RL _i в который U _x задействован. Если регистрация прошла успешно, U _x получает GMK _x , а AS сохраняет пару ID _x и UPK _x в своем собственное хранилище.

Отчет и обратная связь

Когда пользователь хочет отправить предупреждение о событии, которое может помочь другим пользователям, он может загрузить это событие в AS , отправив отчет. Загруженный отчет состоит из трех частей: 1) сообщения о событии (, событие ), 2) скрытого идентификатора (blindIDx) и 3) значения подписи группы.

BlindIDx U _x создается PB.Blind (PPK _AS , rand, ID _x ) после выбора случайного значения ( rand ), который используется для скрытия ID _x из AS .Значение групповой сигнатуры σGMKxGS (event∥blindIDx) создается GS.Sig (GPKRLi, GMK _i , event∥blindIDx), где ∥ - конкатенация.

Когда загруженный отчет передается на AS , σGMKxGS (event∥blindIDx) проверяется через GS.Ver (GPKRLi, σGMKxGS (event∥blindIDx), event∥blindIDx). Поскольку GPKRLi представляет определенный уровень репутации, AS может определить, следует ли публиковать этот отчет, с помощью собственных правил публикации.Например, AS имеет правило, разрешающее публиковать отчеты только тогда, когда отчет проверяется открытым ключом группы, представляющим уровень репутации выше среднего.

Если отчет, загруженный с помощью U _x , успешно опубликован, пользователь получает скрытый жетон вознаграждения от AS . Ослепленный токен, σPSKASPB (blindIDx, Info), создается функцией PB.sig ( PPK _AS , PSK _AS , blindIDx, Info ).Затем функция PB.Info ( Time_Info ∥ RL _i ∥ Token_Report ) используется для создания Info .

Пользователь может впоследствии получить Reward_Token , σPSKASPB (IDx, Info) из своего слепого токена с помощью функции PB. ), который использовался для слепой идентификации.

Аналогичным образом, все пользователи могут загружать отзывы об отчете, чтобы обновить ситуацию или высказать свое положительное или отрицательное личное мнение.Отзыв состоит из трех частей: 1) отзыв об опубликованном отчете ( обратная связь ), 2) слепая идентификация (blindIDx) и 3) значение групповой подписи (σGMKxGS (feedback∥blindIDx)). Значение групповой подписи также проверяется соответствующим GPKRLi. Отзыв может быть использован для оценки опубликованного отчета. Следует отметить, что разработка алгоритма оценки отчета с использованием сообщений обратной связи, таких как EigenTrust [26], выходит за рамки данной статьи.

Пользователи, которые оставляют отзывы, также получают скрытые жетоны вознаграждения, σPSKASPB (blindIDx, Info), от AS .Функция PB.Info ( Time_Info ∥ RL _i ∥ Token_Feedback ) используется для создания Info . Маркер вознаграждения, σPSKASPB (IDx, Info), также можно получить из ослепленных токенов с помощью функции PB.Unblind ( rand , σPSKAS (blindIDx, Info)).

Кроме того, AS требуется для проверки повторяющихся сообщений отчета или сообщений обратной связи, чтобы предотвратить искажение собственной службы из-за дублирования сообщений.Используя функцию GS.Link (GPKRLi, GLKRLi, групповые подписи , сообщения ), AS в BPRF может обнаруживать повторяющиеся отчеты и сообщения обратной связи, представляющие одно и то же событие или контент обратной связи, которые также были сгенерированы один пользователь. Таким образом, пользователи, которые создали повторяющиеся сообщения отчета или сообщения обратной связи, получают Reward_Token только один раз от AS .

Алгоритм 1 : Обновление репутации

Вход : токен ( Reward_token или Penalty_token )

// e.г., σPSKASPB (IDx, Info), PPK _AS , ( ID _x , Info )

Выход : 0 или 1

1

* Это структура (ключ, значение) наподобие сопоставления Solidity * /

2 Map (string → int) ID_Map // ID → replication_value

3 Map (int → int) Token_Map // Token → флаг

4

/ * Это этап проверки с использованием PB.Версия (…) * /

5 , если Проверка токена с использованием PB.Ver (…) , затем

6

/ * Это этап синтаксического анализа с использованием Info , который является результатом PB.Info (…) * /

7 ID строки = ID // из токен

8 int time_info = Time_Info // из токена

9 int RL = RL _i // из токена

10 9016 int token_type // из токена

11

/ * Это шаг для проверки того, действительно ли time_info действителен, а токен не используется * /

12 если (срок действия time_info не истек) и (токен не используется) , затем

13 int replication = ID_Map (ID) // ID's replication_value

14 Token_Map (токен) = 1 // Установка флагов для проверки использования токена

15

/ * Это это один шаг обновления репутации * /

16 если Репутация в пределах RL , затем

17 , если token_type ⩵ Token_Report , затем

18 ID_Map (ID) = репутация + report_point

19 возврат 1

20 иначе, если token_type ⩵ Token_Feedback , затем

21 ID_Map (ID) = репутация + точка обратной связи

22 возврат 1

23 иначе, если token_type ⩵ Token_Trace , затем

24 ID_Map (ID) = репутация — штраф_поинт

25 возврат 1

26 еще

27 возврат 0

28 возврат 0

30 еще

31 возврат 0

32 else

33 возврат 0

Обновление репутации

Пользователи могут загружать заработанные ими жетоны вознаграждения в смарт-контракт AS , который управляет обновлением репутации, когда они хотят их использовать.Согласно предопределенной политике вознаграждения AS , смарт-контракт может повысить значения репутации для любого пользователя, который отправил токены вознаграждения. Алгоритм 1 - это псевдокод смарт-контракта AS для обновления репутации. Однако, если пользователь взаимодействует со смарт-контрактом AS для обновления репутации непосредственно после получения токена вознаграждения за отправленный отчет или отзыв, существует вероятность того, что личность пользователя будет связана с отправленным сообщением о событии.Чтобы решить эту проблему, мы ввели процесс передачи токенов на основе случайной задержки. В этом процессе передачи токенов на основе случайной задержки пользователь должен подождать произвольное количество времени, чтобы отправить свои собственные токены вознаграждения. Случайная задержка определяется случайным числом r , выбранным между 0 и K , где K - системный параметр для этой случайной задержки. Когда количество запросов на обновление репутации, которые могут быть проверены с помощью транзакций алгоритма 1, достигает случайного числа r , пользователь отправляет свои собственные жетоны вознаграждения, накопленные в ожидании r запросов на обновление репутации, в смарт-контракт AS для обновление репутации.Таким образом, все заработанные пользователем токены могут обрабатываться как пакет. Если K достаточно велико, возможность утечки информации сводится к минимуму.

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

Отзыв

Если есть пользователи, которым были назначены новые уровни репутации после процесса обновления репутации, AS создает списки отзыва (например.g., Revo_ListRLi), куда входят все пользователи, чьи уровни репутации изменились. В процессе отзыва AS выполняет GS. (GPKRLi, GTKRLi, Revo_ListRLi) для создания GPKRLinew и Revoke_InfoRLi. AS затем рассылает GPKRLinew и Revoke_InfoRLi всем пользователям, имеющим уровень репутации i ( RL _i ), чтобы инициировать обновление ключей членов группы. Например, пользователь ( U _x ) может обновить свой собственный ключ члена группы через GS.Обновление (GPKRLi, GPKRLinew, GMK _x , Revoke_InfoRLi), который выводит GMKxnew.

В целях компромисса с чувствительным ко времени характером отчета и процесса обратной связи при выполнении GS.Update (GPKRLi, GPKRLinew, GMK _x , Revoke_InfoRLi), BPRF устанавливает период отсрочки для периода времени, в течение которого пользователь продолжает сохранять или использовать свои собственные параметры группы после истечения срока действия этих параметров.Льготный период в качестве системного параметра установлен дольше времени, необходимого для выполнения GS.Update (GPKRLi, GPKRLinew, GMK _x , Revoke_InfoRLi). Если пользователь ( U _x ) был отозван с уровня репутации i и льготный период закончился, пользователь больше не может использовать предыдущий GMK _x , потому что он не поддается проверке от GPKRLinew больше.

Трассировка

Процесс отслеживания запускается, когда AS обнаруживает вредоносный отчет.Обнаружение злонамеренного отчета может быть выполнено с помощью заранее определенных ненормальных условий, таких как поток отрицательных отзывов об одном опубликованном отчете или поток отчетов, несовместимых с другими опубликованными отчетами. Определение аномальных условий варьируется от приложения к приложению. Если AS обнаруживает вредоносный отчет, AS отправляет отчет на TS . Затем TS выполняет функцию трассировки, GS.trace (GPKRLi, ГТКРЛи, σGMKxGS (event∥blindIDx), event∥blindIDx), который выводит UPK _x злонамеренного пользователя и соответствующий τ , который может использоваться, чтобы доказать, что σGMKxGS (event∥blindIDx) имеет отношение к УПК _x .После обнаружения UPK _x из вредоносного отчета TS отправляет σGMKxGS (event∥blindIDx), UPK _x и τ на смарт-контракт AS , который управляет отслеживать события. Этот контракт проверяет, коррелируется ли σGMKxGS (event∥blindIDx) с UPK _x с использованием τ . Информация в этом процессе отслеживания, σGMKxGS (event∥blindIDx), UPK _x и τ , хранится как транзакции смарт-контракта AS для управления трассировкой.

Алгоритм 2 : Трассировка

Вход : Информация трассировки

// т.е. GPKRLi, UPK _x , σGMKxGS (m), m, τ

или Выход 1 : 0

/ * Это структура (ключ, значение), аналогичная отображению Solidity * /

1 Карта (byte [] → int) UPK_Map // UPK _x → counter

2

/ * Это этап проверки с использованием GS.Судья (…) * /

3 , если Подтверждение доказательства (τ) с использованием GS.Judge (…) , затем

4 int counter = UPK_Map (UPK _x )

5 UPK_Map (UPK _x ) = counter + 1

6

возврат 1 else

8 return 0

Алгоритм 2 является псевдокодом для смарт-контракта AS для управления трассировкой.Каждый раз, когда алгоритм 2 вызывается AS , значение счетчика отслеживаемого пользователя увеличивается на 1, если подтверждение трассировки τ было успешно подтверждено. Если значение счетчика, управляемое алгоритмом 2, больше порога, AS выдает маркер штрафа ( Penalty_Token ), то есть σPSKASPB (IDx, Info), в котором Info генерирует PB. Информация ( Time_Info ∥ RL _i ∥ Token_Trace ).Затем Penalty_Token передается в алгоритм 1 для уменьшения значения репутации согласно Penalty_Token .

Посредством этого процесса отслеживания может быть повторно оценен уровень репутации пользователя, отправившего сообщение о злонамеренности на адрес AS .

Обсуждение

Политика управления репутацией

Хотя каждое совместное приложение имеет свою собственную политику управления репутацией, можно применить BPRF к ряду таких приложений.В этом разделе мы приводим один пример (например, Waze), чтобы показать, как BPRF можно применить к реальным приложениям. Как показано на рисунке, Waze имеет политику в отношении очков, заработанных пользователями, и уровней рейтинга. Если пользователь Waze отправляет отчет о дорожных условиях, ему присуждается шесть баллов, и один процент лучших игроков в данном регионе классифицируется как Waze Royalty.

Пример политики управления репутацией.

В этом примере мы представляем две политики BPRF : политику A и политику B.В политике A пять уровней ранжирования Waze и пять уровней BPRF напрямую соответствуют друг другу, как показано на. Однако, поскольку количество пользователей, принадлежащих к Waze Royalty (один процент с высокими показателями) невелико, поведение пользователей, принадлежащих к этому очень высокому уровню репутации, можно легко связать с конкретными областями. Следовательно, в политике B уровни Waze Knight и Waze Royalty объединены, чтобы сформировать наивысший уровень репутации. Таким образом, политики BPRF могут быть определены и настроены для сред совместных приложений.

Сговор между