KR102478132B1 - 사이버보안 장치 및 방법 - Google Patents

사이버보안 장치 및 방법 Download PDF

Info

Publication number
KR102478132B1
KR102478132B1 KR1020207037735A KR20207037735A KR102478132B1 KR 102478132 B1 KR102478132 B1 KR 102478132B1 KR 1020207037735 A KR1020207037735 A KR 1020207037735A KR 20207037735 A KR20207037735 A KR 20207037735A KR 102478132 B1 KR102478132 B1 KR 102478132B1
Authority
KR
South Korea
Prior art keywords
address
wallet
tokens
addresses
transaction
Prior art date
Application number
KR1020207037735A
Other languages
English (en)
Other versions
KR20210014155A (ko
Inventor
김형우
탄청렁
척추안나롱 총
쟈하오도노반 탄
아툴 하리랄
카윙 영
Original Assignee
웁살라 프라이비트 리미티드 컴퍼니
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 웁살라 프라이비트 리미티드 컴퍼니 filed Critical 웁살라 프라이비트 리미티드 컴퍼니
Publication of KR20210014155A publication Critical patent/KR20210014155A/ko
Application granted granted Critical
Publication of KR102478132B1 publication Critical patent/KR102478132B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Abstract

사이버보안 장치 및 방법으로서, 이 장치는, 타겟 블록체인 시스템에서 서브젝트 어드레스에 대한 입력을 수신하고 타겟 블록체인 시스템에서 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 거래의 미리 정해진 수의 홉에 관련된 어드레스들의 리스트를 취득하게끔 장치를 제어하기 위한 메모리의 명령어를 실행하도록 구성된 프로세서를 포함한다. 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 취득된 어드레스들의 리스트 내의 어드레스들의 의심스러운 거래 거동을 장치에 의해 식별한다. 이어서, 의심스러운 거래 거동을 고려하여 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수를 계산한다.

Description

사이버보안 장치 및 방법
본 발명은 사이버보안 장치 및 방법에 관한 것이다.
21세기 디지털 기술의 급속한 발전으로 인해, 더 많은 혁신을 방해하는 정교하고 지능적인 위협이 등장하였다. 예를 들어, 암호화폐의 프레임워크는 자율성을 촉진하는 분산형 시스템에 있다. 이러한 자율성은, 분산형 시스템을 해킹하고 정보 및/또는 디지털 통화를 훔칠 수 있는 개인 및/또는 조직에 대한 추적성을 지원하지 않으므로, 이러한 범죄자에게 징벌적 손해를 부과할 수 없다. 또한, 이러한 불법 거래는 블록체인에 영구적으로 기록되며 불가역적이라는 점을 인식해야 한다. 분산형 암호화폐 시스템에는 위협 방어 시스템이 없으므로, 지금까지 분산형 암호화폐 시스템에 거래 보안을 주입하는 개인과 기업의 어깨에 부담을 주었다.
기업 사용자는 더욱 광범위한 보안 솔루션 및 전문가의 집합 및/또는 더욱 정교한 보안 솔루션 및 전문가에 액세스할 수 있지만, 개별 최종 사용자에게는 자신을 방어할 자원이 훨씬 적다. 저 품질의 보안 소프트웨어 및/또는 저급 하드웨어를 사용하거나 기술 지식과 전문 지식의 부족으로 인해, 상황이 악화된다.
평균적인 암호화폐 사용자가 직면하는 근본적인 보안 문제가 적어도 세 개 있다. 첫째, 이러한 일반 사용자는 시스템 해킹에 매우 취약하다. 또한, 이러한 사용자를 잠재적 타겟으로서 쉽게 식별할 수 있지만, 공격자를 식별하는 것은 어렵다. 그 결과, 이러한 일반 사용자는, 자신에게 해커가 잠재적으로 가할 수 있는 모든 위험을 감수해야 한다.
암호화폐 기술의 기반이 되는 핵심 이데올로기인 분산화(Decentralization)는, 혁신과 불안감이 자율성에 기초하여 번성함에 따라, 혁신을 장려하고 동시에 불안감도 유발한다. 익명성을 기반으로 하는 자율성은 시스템에 큰 책임을 부여한다. 실제로, 사이버 범죄 수의 증가는 이러한 자율성이 대가를 치른다는 증거이다. 시스템의 악용으로부터 보호하기 위한 방어 구조의 부재를 우려하는 추가 원인이 있다. 또한, 블록체인 기술의 급속한 발전은 다양한 사기와 사이버 범죄의 발전을 동반한다. 예를 들어, 사용자의 데이터를 인질로 잡고 사용자 데이터를 풀어주는 대가로 금전적 보상을 비트코인으로 요구하는 새로운 유형의 악성 소프트웨어인 랜섬웨어가 존재한다. 랜섬웨어 "시장"은 2021년까지 173억 6천만 달러로 확장될 것으로 예상된다.
사이버 범죄의 다른 일례는 피싱 공격이다. 이러한 피싱 공격은, 점점 더 많은 개인 및/또는 조직이 하나 이상의 이메일 어드레스를 가짐에 따라, 점점 더 퍼지고 있다. *.doc, *.xls, *.ppt 등의 첨부 문서 파일에 악성 매크로가 삽입된 피싱 이메일은, 사용자를 감염시킬 수 있고, 사용자가 감염된 문서 파일을 열거나 첨부된 악성 링크를 클릭하는 경우 큰 피해를 입힐 수 있다. 예를 들어, 한국의 주요 암호화폐 거래소인 빗썸(bithumb)은 2017년 7월에 해킹당했으며, 감염된 파일이 공개되었기 때문에 31,000명의 고객 및 기업의 기밀 정보가 도난당했다. 현재까지, 이 피싱 공격의 가해자는 아직도 식별되지 않았다.
피싱 공격은 이메일에만 국한되지 않는다. 전화 피싱의 경우에는, 암호화폐 거래소의 운영자로 명의도용하여 자신의 개인 정보를 범죄자에게 공개하도록 많은 개인을 속이는 데 성공한 다양한 사기 방법이 있다. 예를 들어, 해커는, 관리자라고 주장하고 해킹된 사용자 계정의 비밀번호를 재설정하도록 사용자의 개인 정보를 요청할 수 있다. 이어서, 해커는 사용자 계정에 대한 액세스를 얻는다.
비트코인 관련 해킹에 관한 사이버 범죄의 또 다른 일례가 있다. 이 사이버 범죄는 초기 코인 공개(ICO) 중에 발생할 수 있으며, 이때, 가짜 ICO 모금 사이트를 생성하고 허위 정보를 제공함으로써, 해커는 ICO 자금을 받기 위해 지정된 지갑 어드레스를 교체하고 자신의 고유한 지갑 어드레스로 바꿀 수 있다.
또 다른 일례로, 2016년에 있었던 분산형 자율 조직(DAO) 사건은, 코드 취약성에 대한 공격으로 인해 이더리움 총 공급량의 약 15%를 해커에게 노출시켰다. 그 결과 수만 명의 투자자가 재정적 손실을 입었다. DAO 사건의 손실을 줄이기 위해 "하드 포크"(hard fork)를 구현해야 했으며, 이러한 구현은 블록체인 불변성의 근본적인 특성을 위반하였다. 하드 포크는, 이전 규칙에 따라 유효성 검증을 행하는 소프트웨어가 새 규칙에 따라 생성된 블록을 무효한 것으로서 간주하도록 하는 블록체인의 규칙 변경이다. 하드 포크의 경우, 새 규칙에 따라 동작하는 모든 노드는 자신의 소프트웨어를 업그레이드해야 한다.
이러한 사이버 범죄가 발생하는 이유 중 하나는, 인터넷의 개방성으로 인해 피해자가 쉽게 타겟으로 되기 때문이다. 분산화의 이데올로기는 암호화폐와 인터넷 모두의 핵심이지만, 개방성의 자율성은 개인의 책임을 따른다.
요약하면, 분산형 암호화폐 시스템에 연관된 위험이 존재하며, 자율적 환경에 내재된 고유한 취약성은 개인의 경고에 크게 의존한다.
본 개시 내용의 예시적인 양태들을 독립항들에 제공한다. 본 개시 내용의 예들의 선택적인 일부 특징은 종속항들에 정의되어 있다.
일부 도면에서, 유사한 요소는 다른 도면에서 유사한 참조 번호로 표시된다. 본 발명의 실시예들은, 단지 예로서만 그리고 도면들과 관련하여 다음에 기재된 설명으로부터 당업자에게 더 잘 이해되고 쉽게 명백해질 것이다.
도 1은 본 개시 내용의 일례에 따라 제안된 센티넬 프로토콜에 사용되는 기술 아키텍처의 일례를 도시한다.
도 2는 본 개시 내용의 일례에 따라 블록체인용 보안 지능 플랫폼(SIPB)을 위해 구현된 자동보고 및 수동보고의 일례를 도시한다.
도 3은 본 개시 내용의 일례에 따라 데이터 블록이 블록체인에서 생성되는 때를 결정하는 데 사용되는 고레벨 합의 다이어그램의 일례를 도시한다.
도 4는 본 개시 내용의 일례에 따라 진본(실제) 트위터 계정과 명의도용된(허위) 트위터 계정 간의 비교를 도시한다.
도 5a와 도 5b는 트위터 계정이 피싱 캠페인으로 어떻게 감염될 수 있는지에 대한 예를 도시한다.
도 6a 내지 도 6c 및 도 7은 명의도용된 계정에서 악성 행위자가 사용하는 일반적인 트릭을 도시한다.
도 8a 내지 도 8d는 본 개시 내용의 일례에 따라 트위터 크롤러 시스템에 대하여 구현된 작업 흐름을 도시한다.
도 9는 본 개시 내용의 일례에 따라 트위터 크롤러에 대하여 구현된 악성 트위트 체크를 도시한다.
도 10a는 본 개시 내용의 일례에 따라 검출된 결과가 어떻게 처리(후-검색)되는지를 도시한다.
도 10b와 도 10c는 본 개시 내용의 일례에 따라 구현될 수 있는 다른 선택적 특징들을 도시한다.
도 11 내지 도 15는 센티넬 프로토콜의 API를 사용할 때 사용자에게 표시되는 경고의 표시를 수정하는 데 사용되는 미리 정의된 설정의 일부 예를 도시한다.
도 16a와 도 16b는 본 개시 내용의 일례에 따라 사기성 암호화 어드레스 및 진본성 암호화 어드레스의 경고 표시가 각각 어떻게 표시되는지를 도시한다.
도 17a와 도 17b는 본 개시 내용의 일례에 따라 각각 명의도용된 계정 및 진본성 계정을 표시하도록 트위터 배지가 어떻게 구현될 수 있는지를 도시한다.
도 18은 본 개시 내용의 일례에 따라 포스트에 악성 콘텐츠가 있음을 나타내기 위해 트위터 포스트에 오버레이가 어떻게 구현될 수 있는지를 도시한다.
도 19a는 암호화 분석 위험 평가 알고리즘의 3개 기능을 도시한다.
도 19b는 검사된 지갑으로부터 유래되는 거래 흐름을 나타내는 맵을 도시하고 맵의 특징을 소개한다.
도 20a 내지 도 20f는, 블록체인에서 검사된 지갑의 바로 이웃하는 지갑을 악성, 비악성, 의심스러운 것으로 결정할 수 있는 검사된 지갑으로부터 유래되는 거래 흐름의 상이한 순열을 갖는 맵을 도시한다.
도 21은 거래 흐름 정보가 검사된 지갑이 다른 지갑과 어떻게 거래하는지를 나타내는 태스크로 변환되는 방법을 도시한다.
도 22는 검사된 지갑에 대해 악성을 나타내는 위험 점수가 어떻게 계산되는지를 도시한다.
도 23a 내지 도 23c는 위험 점수를 결정하기 위한 메트릭 값을 계산하도록 특별한 고려를 필요로 하는 세 가지 다른 태스크의 예를 도시한다.
도 24는 본 개시 내용의 일례에 따른 암호화 분석 거래 시각화(CATV) 애플리케이션의 시스템 아키텍처 프레임워크를 도시한다.
도 25는 사용자가 CATV 애플리케이션에 의해 생성된 시각화 다이어그램의 노드 위에 마우스를 올리거나 노드를 클릭하면 나타나는 라벨의 일례를 도시한다.
도 26은 CATV 애플리케이션의 시각화 엔진에 의해 생성된 시각화 다이어그램의 일례를 도시한다.
도 27은 본 개시 내용의 일례에 따른 거래 엔진에 의해 생성된 거래 테이블을 도시한다.
도 28은 시각화 다이어그램을 생성하도록 검색 파라미터를 입력하는 데 사용되는 검색 패널을 도시한다.
도 29는 검색되는 암호화 지갑 어드레스(목적지 깊이 = 2)의 순방향 거래의 흐름도의 일례를 도시한다.
도 30은 도 29의 거래 흐름(소스 깊이 = 1; 목적지 깊이 = 1)에서 유래되는 다른 일례를 도시한다.
도 31은 검색되는 암호화 지갑 어드레스(목적지 깊이 = 2)의 역방향 거래의 흐름도의 일례를 도시한다.
도 32는 도 31의 흐름도의 일부의 확대도를 도시한다.
도 33은 검색되는 암호화 지갑 어드레스(목적지 깊이 = 4)의 순방향 거래의 흐름도의 일례를 도시한다.
도 34는 도 33의 흐름도의 확대도를 도시한다.
도 35는 8로서 설정된 고 볼륨 노드(HVN) 파라미터의 임계값으로 검색되는 노드의 흐름도의 다른 일례를 도시한다.
도 36은 HVN 파라미터의 임계값이 4로 설정된 경우 도 35의 수정된 흐름도이다.
도 37은 본 개시 내용의 일례에 따라 분산형 거래소(DEX)와 관련하여 사용되는 3가지 기본 기능(입금, 거래, 인출)을 도시한다.
도 38a와 도 38b는 본 개시 내용의 일례에 따라 사용자가 거래소에 입금하였을 때의 자금 흐름의 일례를 도시한다.
도 38c는 본 개시 내용의 일례에 따라 추가 사용자 지갑을 식별하는 데 거래소 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 38d는 본 개시 내용의 일례에 따라 추가 거래소 지갑 및/또는 사용자 지갑을 식별하는 데 중계 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 38e는 본 개시 내용의 일례에 따라 추가 거래소 지갑 및/또는 사용자 지갑을 식별하는 데 사용자 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 39는 본 개시 내용의 일례에 따라 추가 분석을 위해 스마트 계약 어드레스가 어떻게 수집되고 사용될 수 있는지에 대한 일례를 도시한다.
도 40은 본 개시 내용의 일례에 따른 사용자 지갑 검증의 개략도이다.
도 41a는 본 개시 내용의 일례에 따라 (분산형 지갑을 갖는) 중앙 집중형 거래소의 중계 지갑이 어떻게 식별될 수 있는지를 도시한다.
도 41b는 본 개시 내용의 일례에 따라 추가 사용자 지갑을 식별하는 데 도 41a의 식별된 중계 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 42a는 본 개시 내용의 일례에 따라 도 41a의 예에서 인출 중계 지갑이 어떻게 식별될 수 있는지를 도시한다.
도 42b는 본 개시 내용의 일례에 따라 추가 중계 지갑을 식별하는 데 도 41a의 식별된 중계 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 42c는 본 개시 내용의 일례에 따라 인출이 이루어진 후 중계 지갑이 3개의 다른 중계 지갑으로 어떻게 분할되는지를 도시하는 일례이다.
도 42d는 본 개시 내용의 일례에 따라 업비트(Upbit) 거래소의 더 많은 핫 지갑 또는 중계 지갑을 식별하는 데 업비트 거래소의 사용자 예금 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 42e 내지 도 42g는 도 42d의 예로부터 핫 지갑 또는 중계 지갑을 결정하는 데 지갑의 거래 이력이 어떻게 사용될 수 있는지를 도시한다.
도 42h는 본 개시 내용의 일례에 따라 업비트 거래소의 더 많은 중계 지갑을 식별하는 데 업비트 거래소의 핫 지갑이 어떻게 사용될 수 있는지를 도시한다.
도 43은 사용자 지갑이 중앙 집중형 지갑을 갖는 중앙 집중형 거래소와 어떻게 상호 작용할 수 있는지를 도시하는 개략도이다.
도 44는 사용자 지갑이 분산형 지갑을 갖는 중앙 집중형 거래소와 어떻게 상호 작용할 수 있는지를 도시하는 개략도이다.
도 45는 개별 지갑이 DEX와 어떻게 상호 작용할 수 있는지를 보여주는 개략도이다.
도 46은 (분산형 지갑을 갖는) 중앙집중형 거래소의 중계 지갑이 거래소의 다른 사용자 지갑, 인출 중계 지갑, 및/또는 중계 지갑과 어떻게 상호 작용하는지를 도시하는 개략도이다.
도 47은 본 개시 내용의 일례에 따른 지갑 크롤러 시스템의 메인 메뉴(Graphical user interface)의 일례이다.
도 48은 본 개시 내용의 일례에 따라 거래소 지갑 어드레스로부터 사용자 지갑을 결정 및/또는 유효성 검증하도록 지갑 크롤러 시스템이 어떻게 구성되는지에 대한 흐름도이다.
도 49a 내지 도 49c는 본 개시 내용의 일례에 따라 도 48의 사용자 지갑 유효성 체크 프로세스 및 식별되지 않은 지갑이 어떻게 처리될 수 있는지를 도시한다.
도 50은 본 개시 내용의 일례에 따라 블록체인 탐색기 애플리케이션을 통해 식별된 스팸 어드레스의 일례이다.
도 51은 본 개시 내용의 일례에 따라 블록체인 탐색기 애플리케이션을 통해 식별된 스팸 어드레스의 다른 일례이다.
도 52와 도 53은 본 개시 내용의 일례에 따라 CATV 애플리케이션의 필터 경로 기능이 가상화 다이어그램의 두 개 노드 간의 경로를 어떻게 강조할 수 있는지를 도시한다.
도 54는 본 개시 내용의 일례에 따라 위협 평판 데이터베이스를 관리하기 위한 장치, 센티넬 소유의 센티넬 장치, 및 센티넬 프로토콜을 활용하는 개인 소유의 사용자 장치 간의 SIPB의 일례이다.
도 55는 본 개시 내용의 일례에 따른 지갑 크롤러 주석 데이터베이스(WCDB)에 저장된 데이터의 일례이다.
사이버보안은 오늘날의 세계에서 우려 사항이며, 사이버 범죄는 개인 및/또는 조직에 심각한 영향을 미칠 수 있다. 이 영향은 블록체인 기술의 보급으로 증가할 수 있다.
블록체인 기술은, 넓은 의미에서, 중앙 기관의 제어를 필요로 하지 않는 완전한 P2P 시스템에 관한 것이다. 대신, 블록체인 기술을 사용하는 거래(예를 들어, 비트코인, 이더리움 등의 디지털 통화 송금)는 비신뢰 네트워크(trust-less network) 내에서 합의 알고리즘을 사용하여 완료된다. 블록체인 거래의 정산 과정에서, 지배적인 규칙은, 누구나 보고/또는 검증할 수 있도록 모든 기록(record)이 공유되고 공개된다는 점이다. 그러나, 이는, 민감한 개인 자산의 정보 공개가 거래의 기술적 측면으로부터 분리될 수 없기 때문에, 금융 상품의 상업화에 약간의 구현 어려움을 초래할 수 있다. 실제 아이덴티티를 보장하지 않으면, 사용자는 관리 규칙과 규정이 더욱 엄격해지지 않는 한 다양한 금융 서비스에 참여하기를 꺼릴 수 있다. 제안된 한 해결책은, 공공 분산화의 모든 잠재력을 활용하지 않는 컨소시엄 블록체인을 사용하는 것이다. 게다가, 이러한 정보의 완전한 공개가 분산화의 모든 이점을 활용하는지 여부도 의문이다.
본 개시 내용의 발명자들은, 현재의 사이버 범죄에 관련된 정보 및 블록체인 기반의 평판 시스템을 블록체인 분산 정책 내에서 공유할 수 있다면 분산형 블록체인 시스템이 보안 위협에 대하여 더욱 강력해질 것이라는 견해를 갖고 있다.
그러나, 검출된 사이버 범죄에 관한 정보의 조작과 파괴는 다소 어려울 수 있다. 악성 의도를 가진 개인 또는 그룹이 조직 또는 시스템의 평판을 조작하거나 블록체인 기반 시스템을 해킹하여 기록된 평판을 조작하는 경우, 후자의 경우는 블록체인의 데이터 무결성의 이점에 의해 해결될 수 있다.
그러나, 거래(transaction)가 아닌 정보의 질을 평가하는 평판 시스템에서, 시빌(Sybil) 공격 등의 공격은, 거래 평판에도 불구하고 미리 조작된 정보가 기록될 수 있게 하는 미리 조작된 정보의 주관적 성질로 인해, 블록체인의 기본 특성에 의해 쉽게 패배할 수 없다.
이러한 단점은 집단 지능을 통해 완화될 수 있다. 다음 단락은 제안된 사이버보안 장치 및 방법의 예에 관한 것이다.
제안된 사이버보안 장치 및 방법에 따르면, 분산화의 단점(들)을 보안의 장점으로 전환함으로써 극복할 수 있는 방법 및 장치를 제공한다. 이 방법은 센티넬 프로토콜에 의해 관리되며, 장치는, 메모리, 및 장치를 작동시켜 방법의 일부 단계들을 실행시키는 메모리 내의 명령어를 실행하도록 구성된 처리 유닛(예를 들어, 컴퓨터, 프로세서 등)을 포함할 수 있다. 분산화의 장점을 활용하여 생성된 집단 지능 시스템을 이용함으로써, 센티넬 프로토콜은 암호화 기능과 지능 기반 위협 분석 알고리즘을 결합하여 안전하고 혁신적인 에코시스템을 생성하도록 구성된다. 본원에서 사용되는 "센티넬 프로토콜"이라는 용어는, 시스템, 또는 구체적으로 장치를 포함하는 분산형 시스템도 지칭하며, 이러한 분산형 시스템은 센티넬 프로토콜이 관리하는 방법을 사용하며 인공 지능을 사용할 수 있다는 점에 주목한다. 간략화를 위해, "센티넬 프로토콜" 및 "블록체인용 보안 및 지능 플랫폼"(Security and Intelligence Platform for Block chain, SIPB)이라는 용어들은, 본원에서 서로 바꿔서 사용될 수 있다. 그러나, 명확히 하도록, 센티넬 프로토콜은 소프트웨어 구성 요소에 관한 것인 반면, SIPB는 센티넬 프로토콜을 포함하는 하드웨어 구성요소와 소프트웨어 구성요소를 모두 포함할 수 있다. 전술한 장치는, 센티넬 프로토콜 시스템에서 복수의 노드에 있는 노드, 또는 두 개 이상의 노드를 포함하거나 운영하는 장치일 수 있다. 센티넬 프로토콜, 이에 연관된 방법, 장치, 및/또는 시스템에 대한 자세한 내용은 이하에 제공된다.
센티넬 프로토콜을 통해, 대중은 피싱 도메인, 지갑 어드레스, 악성 소셜 미디어 URL 등의 악성 활동을 SIPB에 보고할 수 있으며, 각각의 보고된 사례는 센티넬(크라우드소스 사이버보안 전문가)에 의해 평가된다. 센티넬은 시스템 관리자일 수 있다. 센티넬 프로토콜은 블록체인의 특징을 포함할 수 있다. 센티넬은 블록체인 네트워크의 노드 사용자일 수 있다. 센티넬은, 자신을 블록체인 네트워크에 센티넬로서 등록할 수 있고, 또는 블록체인 네트워크에 의해 선택/투표될 수 있어서, 보고된 사례의 유효성 검증/평가를 수행할 수 있다. 각 유효성 검증/평가는 블록체인 네트워크의 거래일 수 있다. 블록체인 네트워크의 노드는, 사용자가 운영하는 컴퓨터, 단말, 또는 장치를 지칭할 수 있다. 센티넬에 대한 자세한 내용은 나중에 제공된다.
센티넬에 의해 유효성 검증된/평가된 데이터는 블록체인 네트워크에 데이터 블록으로서 저장될 수 있다. 예를 들어, 유효성 검증된/평가된 데이터는 위협 평판 데이터베이스에 저장될 수 있다. 이러한 위협 평판 데이터베이스는, 예를 들어, EOS 블록체인과 같은 블록체인에서 커밋(commit)될 수 있다. EOS 블록체인의 일례는 https://eosflare.io/account/eosioupptrdb이다. 일례로, 위협 평판 데이터베이스는, 암호화 지갑 어드레스, 도메인, 호스트명, IP 어드레스, URL 등을 포함하는 위협 데이터를 지원할 수 있다.
본원에서 사용되는 "웁살라 시큐리티"(Uppsala Security)라는 용어는 센티넬 프로토콜을 구현 및/또는 마케팅하는 데 관여하는 조직을 지칭한다. 이 용어는 전문 용어로 읽어서는 안 된다.
분산형 시스템의 논의된 보안 허점을 해결하는 것은 전체 암호화폐 커뮤니티의 책임이며, 따라서, 문제를 해결하려는 개별적인 시도는 부적절하고 비효율적이다. 집단 지능을 활용하여 일반 대중의 이익을 보호하는 분산형 사이버보안 생태계를 생성할 수 있다.
제안된 사이버보안 장치 및 방법에 따르면, 자율성의 기본 원칙을 유지하면서, 공격자(들)의 미식별된 공격 패턴을 검출하고, 검출된 정보를 생태계 전체에 전파하고, 집단 지능을 통해 분산형 인공 지능 시스템의 모든 구성원을 보호하도록 구성된 분산형 인공 지능 시스템을 제공한다. 분산형 인공 지능 시스템과 센티넬 프로토콜에 대한 자세한 내용은 본 개시에서 나중에 논의될 것이다.
집단 지능
본원에서 사용되는 "집단 지능"이라는 용어는, 지갑 어드레스, URL, 호스트명, IP 어드레스, 도메인 등과 같이 온라인 거래(예를 들어, 블록체인 거래)의 필드를 인증하기 위해 분산형 시스템의 사용자가 보고하는 정보를 사용하는 것을 포함한다. 이들 사용자는, 암호화폐 거래소의 관리자, 암호화폐 거래를 수행하는 사용자, 및/또는 블록체인에 대한 미보안 링크 또는 위협을 식별하기 위해 해당 기술 지식을 공유하도록 장려될 수 있는 보안 전문가(보안 공급업체라고도 함)를 포함한다. 일례로, 전문가 패널에 의해 철저히 검증, 자격 검증, 및 인증된 개인이나 기관은, 블록체인에서 조사 결과를 업데이트할 권한이 있다.
사이버 범죄와 관련된 정보를 블록체인과 결합함으로써, 데이터의 공유된 경제 원칙으로 인해 많은 모방 범죄를 신속하게 식별 및/또는 예방할 수 있다. 이러한 구현은, 사이버 범죄 조사 프레임워크를 완성하고, 잠재적 보안 위협에 대한 인식을 제공한다. 예를 들어, 암호화폐를 표적으로 삼는 사이버 범죄자들이 (분산형 시스템의 자율성에도 불구하고) 사용자들의 개인 정보에 액세스하는 것이 개념적으로 가능하다.
블록체인은, 본질적으로 모든 거래가 분산 원장에 기록되고 특별한 허가 없이 누구에 의해서도 검증될 수 있기 때문에 정보를 투명하게 공유하는 시스템이다. 이는 이들 거래를 추적할 수 있음을 의미한다. 이는 사이버 범죄에 의해 도용되는 암호화폐 거래의 흐름을 쉽게 추적할 수 있음을 의미한다.
그러나, 암호화폐 거래소와 코인 시프트 시스템을 통한 자금 세탁에 의해 추적성을 벗어날 수 있다. 암호화폐의 현금 가치는, 돈으로 교환되지 않으면 손실된다. 거래소가 있기 때문에 악순환이 발생한다. 이는, 결국 BlockSci와 같은 거래 분석 프로젝트(transaction analysis projects)에 연관된 대화형 협력 프레임워크(Interactive Cooperative Framework)를 통해 추적성을 향상시키기 위해 현금화를 위한 거래소가 필요하므로, 거래 정보를 숨기는 Dash, Zcash, 및 Monero와 같은 자율 거래 코인에도 동일하게 적용된다.
사이버 범죄와 싸우기 위해 암호화폐 거래소들이 협력하는 것은 불가능하지 않지만, 암호화폐 거래소는 또한 엄격한 규정에 따라 사용자의 프라이버시를 보호하기 위해 노력한다. 대부분의 암호화폐 거래소는, 사용자의 기밀을 보호해야 하는 기본 의무를 충족하기 위해 경찰이나 정부 수사 기관의 동의 없이는 협력할 수 없다는 점에 동의해야 한다. 그러나, 암호화폐 규제는 전세계 국가마다 다르며, 현지 수사 기관에서 암호화폐에 대한 전문 지식을 보유한 전문가의 도움을 받기가 어렵다. 또한, 대부분의 국가는 암호화폐 관련 사이버 범죄를 실제 금융 범죄로 취급하지 않는다. 이는 법률 시스템에 의해 보호받지 못하는 사람들이 재정적 손실의 위험을 감수하는 사람들이라는 것을 의미한다.
불변 데이터베이스(immutable database)에 존재하고 발생하고 의심스러운 모든 사이버 범죄에 관한 정보를 포함하는 블록체인은 분산형 조사 시스템을 지원할 수 있다. 모든 정보는 개인, 거래소, 프로젝트, 보안 회사, 정부 등에 즉시 투명하게 될 수 있으며, 가장 중요한 것은 정보를 하나의 시스템 내에서 전 세계의 모든 사람이 추적할 수 있다는 것이다.
따라서, 집단 지능을 기반으로 구축된 평판 시스템은 단순성의 이점을 제공한다. 이는, 거래소가 사용자의 부담을 더하는 복잡한 법적 증거 없이도 평판 시스템을 참조하여 사전 조치를 취할 수 있음을 의미한다. 이를 통해 암호화폐 업계에서 발생하는 많은 사이버 범죄를 예방하고 제어할 수 있다.
집단 지능을 활용하는 것 외에도, 인공 지능(예를 들어, 머신 러닝, 딥 러닝을 통해)을 사용하여 잠재적 보안 위협을 식별할 수 있다.
인공 지능
인공 지능의 메커니즘은 최적화된 알고리즘을 사용하여 대량의 양질 데이터를 모델링하는 것이다. 공격자는, 개인, 그룹, 정부, 기업, 또는 조직을 대상으로 할 때 오랜 기간(들)에 걸쳐 시스템 취약성을 악용하기 위해 예기치 않은 수의 공격을 지능적으로 사용하는 경우가 많다. 이후, 해커의 외부 사령탑과의 지휘 및 제어 통신 채널을 확립한다. 해커의 외부 사령탑과 통신 채널을 확립한 후에는 이미 내부 망에 성공적으로 진입한 공격자의 거동을 파악하는 것이 어려울 것이다. 이는, 기존 보안 기술이 공격의 정확한 이진 표현(binary representation)을 서명으로서 만드는 데 있어서 합법적인 개체의 거동을 의심할 수 있는 기능이 없기 때문이다. 이러한 이유로, 많은 공격은 대상 개인 및/또는 조직에 의해 일반 사용자의 일상적인 패턴으로서 인식된다.
따라서, 분산형 인공 지능 시스템(로컬 머신 러닝 엔진)은, (외형, 즉, 디지털 서명 등 대신) 사용자의 거동 변화를 추적하도록 제공 및 구성될 수 있다. 마찬가지로, 외형의 변화가 아닌 사소한 거동의 변화와의 상관관계를 비교함으로써, 분산형 인공 지능 시스템은 경험적 위험을 미리 인식하도록 구성될 수 있고, 사기 예방 가능성을 높이도록 구성될 수 있다.
도 1은 사용자 거동의 변화를 추적하는 데 사용되는 기술 아키텍처의 일례를 도시한다.
분산형 시스템(100)은, 블록체인을 위한 보안 지능 플랫폼을 제공하며, 다음에 따르는 구성요소를 포함한다.
* S-지갑: 통합 보안 지갑(120)
* 사용자 입력(130a), 거래 데이터(130b), 시스템 로그(130c), 및 패킷 데이터(130d)를 포함하는 사용자 데이터(130)
* 필터링 엔진(122): 암호화폐 어드레스 필터링, 사기 관련 도메인, 파일 필터링
* 머신 러닝 엔진(124): 전술한 바와 같이 거동 분석을 위한 로컬 머신 러닝 엔진
* 분산형 샌드박스(126): 분산형 악성 코드 분석 샌드박스
* 위협 평판(Threat Reputation) DB(110): 사이버 범죄 정보가 플러그인 특징을 포함하는 블록체인 상의 지능 데이터베이스(DB): 향후, 제삼자 암호화폐 지갑과 통합된 VPN 등의 더욱 강화된 보안 기능(127)이 추가될 예정
* 센티넬(150): 인증되고 자격 검증된 집단 지능 그룹 및 개인
* 대화형 협력 프레임워크(Interactive Cooperation Framework, ICF; 160): 근본 원인 분석, 사고 대응, 및 전세계 활동 통계 등의 센티넬 및 공용 사용자 활동을 위한 대시보드인 센티넬 포털이라고도 함.
다음 단락에서는, 블록체인(100)을 위한 센티넬 프로토콜 및/또는 보안 지능 플랫폼을 사용하여 블록체인 기술과 인공 지능을 함께 결합할 수 있는 방법에 대한 두 가지 예를 설명한다.
첫 번째 예에서, 분산형 인공 지능 시스템(100)은, 사용자 또는 노드의 정보를 수집하고 거래 패턴을 포함하여 컴퓨터 사용 패턴의 정상적인 활동과 같은 모든 측면의 모델 거동을 생성하는 머신 러닝 기반 블록체인 보안 클라이언트 지갑(S-지갑(120)이라고도 하며, 세부 사항은 나중에 자세히 설명함)을 제공한다. 의심스러운 거동이 발생하면, 보안 지갑(120)은 위협 가능성을 인식하고 프로세스 실행을 차단한다. 상세한 정보는 집단 지능 그룹(150)에 보고되고 평판 시스템(100)과 공유된다. 모든 정보는 애플리케이션 프로그래밍 인터페이스(API)를 통해 그 정보를 사용하고자 하는 모든 사람에게 공유되며, 이것은 세계에서 가장 정확하고 안전한 글로벌 지능 시스템으로 되도록 확장될 수 있다.
두 번째 예에서는, 블록체인의 데이터를 사용하여 사기 검출 시스템(Fraud Detection System, FDS)이 구성된다. 본질적으로, 센티넬 프로토콜의 이상 검출은 센티넬 그룹이 도달한 합의 시스템과 연관이 있다. 센티넬(150)은, "국제 사이버 범죄 경찰"로서 기능하도록 SIPB(블록체인용 보안 지능 플랫폼)의 초기 단계에서 다수의 전문가(또는 처음에는 토큰 공급업체 및/또는 그 계열사들)("웁살라 시큐리티")에 의해 인증된 개인들의 그룹일 수 있다. 센티넬은, 머신(예를 들어, A.I. System)에 의해 교체될 수 있으며 센티넬이 행하는 작업이 머신에 의해 자동화되는 것이 가능하다. 센티넬(150)은, 연구 및 분석을 담당하며, 평판 시스템을 업데이트하는 특별한 권한이 있다. 센티넬은, 후술할 센티넬 프로토콜의 공유 경제 시스템을 통해 자신의 작업에 대한 보상을 받는다. 내부자 위협을 방지하기 위해, 사기 검출 시스템(FDS)을 설치하여, 집단 지능에 대한 비정상적 지능 및 일반 사용자의 비정상적 거래를 감시하고 검출한다. 종래의 은행 거래 감시 시스템과 유사하게, 디지털 자산 FDS는, SIPB가 수집하고 처리하는 정보를 이용하는 암호화폐 거래에 배치될 수 있다. 다른 일례로, 상술한 예에서 설명된 기술들을 조합하여 사용할 수 있다. 집단 지능을 통해, 보안 정보는, 블록체인 및/또는 센티넬들 간에 공유 및/또는 유효성 검증될 수 있으며, 이후에 사용을 위해 데이터베이스에 저장된다.
보안 기능
블록체인용 보안 지능 플랫폼(SiPB 또는 간단히 센티넬 프로토콜; 100)은 다음과 같은 고유한 보안 기능을 가질 수 있다.
* 위협 평판 데이터베이스(Threat Reputation Database, TRDB; 110)
* 머신 러닝(ML) 엔진 통합 보안 지갑(S-지갑; 120)
* 분산형 악성 코드 분석 샌드박스(Distributed Malware Analysis Sandbox)(D-샌드박스; 126).
센티넬 프로토콜은, 예를 들어, 통합 보안 지갑(S-지갑)(120)을 통해 도 1을 참조하여 후술하는 모든 보안 기능(TRDB, ML, D-샌드박스)을 제공할 수 있다. 그러나, API를 통해 제삼자 네트워킹을 사용하도록 각 기능을 구성할 수 있다. 통합 보안 지갑(120)은 자동 보고(Auto Reporting)와 수동 보고(Manual Reporting)인 두 가지 기능으로 구현되며, 이에 대해서는 추후 도 2를 참조하여 자세히 설명한다.
위협 평판 데이터베이스( TRDB )
다음 단락은, 본 개시 내용에서 제안된 기술과의 차이점 및 이러한 차이점에 연관 이점을 강조하기 위해 기존의 종래 기술을 참조할 수 있다.
본 개시 내용의 일례에서, 위협 평판 데이터베이스(TRDB; 110)는 기존의 사이버 보안 업계에서 다음과 같은 문제를 완화 또는 제거하도록 제공된다.
1. 기존의 사이버 보안 업계의 현재 아키텍처는, 집중형 서버(centralized server)를 참조하는 복수의 사용자에 의한 인증 또는 체크를 위해 위협 정보를 저장하도록 구성된 적어도 하나의 집중형 데이터베이스(centralized database)를 포함한다. 이러한 집중형 데이터베이스는 정보 조작 및 남용에 취약하다. 데이터베이스는 시빌 공격, 또는 서버 해킹, 및 서비스 중단의 명백한 표적이 된다. 예를 들어, 2017년 10월에, 러시아의 국가 해커는 잘 알려진 바이러스 백신 회사인 Kaspersky의 안티바이러스 소프트웨어를 사용하여 국가 안보국 자료를 훔쳤다. 아이러니하게도, 이 사건에서, 해커는 Kaspersky에서 제공하는 보안 도구를 사용하여 대상의 취약성을 찾았다. 대조적으로, (본 개시 내용의 예를 위해 제안된) 블록체인의 분산형 성질은, 데이터 불변성에 의해 해커가 데이터를 변조하기 어려우므로, 이 문제를 완화할 수 있다. 이것은 데이터를 제공하는 서버의 보안 안정성을 증가시킨다.
2. 보안 공급업체들 간에 공유되는 지식이 부족하다. 수집된 위험 정보가 많을수록, 사이버 범죄를 예방할 가능성이 높아진다. 그러나, 현재의 최신 기술에서는, 각 보안 공급업체가 '승자 독식 방식'으로 위협 정보를 자체적으로 수집한다. 공급업체나 사용자가 하나의 포괄적인 데이터베이스를 공동 작업하고 생성하는 것에 대한 인센티브가 없다. 영업권만으로는 확장되지 않으므로, TRDB(110)는, 보안 전문가, 일반 사용자, 및/또는 공급업체가 합의 메커니즘과 참가자의 피드백에 따라 또는 위임 지분 증명(DPOS)을 통해 TRDB(110)에 기여하도록 장려하는 인센티브 체계를 사용한다. 집단 지능을 통해, TRDB(110)는, 해커의 지갑 어드레스, 악성 URI, 피싱 어드레스, 멀웨어 해시를 효율적으로 수집할 수 있고, 사용자가 (지갑 어드레스, 피싱 어드레스, 악성 URI, 및 멀웨어 해시 등의) 이러한 악성 데이터에 액세스하여 귀중한 정보를 잃는 것을 방지할 수 있다.
일례로, TRDB(110)에서 데이터 무결성을 유지하기 위해, TRDB(110)는, 허위 긍정(false positives)과 같은 시스템 에러를 제거하기 위해 보안 전문가(150)에 의해서만 업데이트되도록 구성된다. 일반 사용자도, 검출된 보안 위험에 대한 자동보고 및/또는 검출된 보안 위험에 대한 수동 보고를 허용함으로써 참여할 수 있다. 더 많은 사용자가 TRDB(110)에 기여할수록, 개인 및/또는 조직을 사기 및 신용 사기로부터 더욱 강력하게 보호한다.
이러한 예에서, 사용자가 자동 보고를 허용하면, 머신 러닝 기반 보안 지갑(120)(후술함)으로부터 자동으로 검출되는 알려지지 않은 위협이 TRD(110)에 기록된다. 수동 부고를 통해, 사용자는 (센티넬(150)을 포함하는) 커뮤니티에 의해 유효성 검증될 위험 정보를 보고할 수 있다. 이는, 보고된 데이터가 TRDB(110)에 블록체인의 데이터 블록으로서 등록되기 전에 센티넬(150)(및/또는 센티넬 프로토콜의 시스템 관리자)에 의해 검토 또는 유효성 검증된다는 것을 의미한다.
TRDB(110)는 API로서 제공될 수 있으므로, 임의의 개인 또는 조직(예를 들어, 암호화폐 지갑 프로젝트, 암호화폐 거래소, 및 보안 공급업체)이 정보를 사용할 수 있다. 대안으로, TRDB(100)는, 정기적으로 또는 실시간으로 TRDB(100)에 보안 업데이트를 다운로드하여, 개인 또는 조직에 로컬로 제공될 수 있다.
머신 러닝(ML) 엔진 통합 보안 지갑(S-지갑)
다음 단락은, 본 개시 내용에서 제안된 기술의 차이점 및 이러한 차이점에 연관된 이점을 강조하기 위해 기존의 종래 기술을 참조할 수 있다.
센티넬 프로토콜은 안티바이러스 소프트웨어 기능을 가진 S-지갑(120)을 제공한다. S-지갑(120)과 현재의 최신 안티바이러스 소프트웨어 간의 근본적인 차이점은, 최신 기술의 안티바이러스 소프트웨어가 새로운 위협에 대응하기 위해 최적화되어야 한다는 점이다. 이는, 안티바이러스 소프트웨어가 알려진 모든 새로운 서명에 대해 집중형 서버를 통해 최신 업데이트를 받아야 함을 의미한다. 이러한 방안은 제로-데이 공격(zero-day attacks)과 같은 알려지지 않은 위협에 대응하는 데 효율적이지 않을 수 있다. 이에 비해, S-지갑(120)은, 위협 경향과 이력을 분석하여 알려지지 않은 위협이나 제로-데이 공격에 선제적으로 대응하도록 구성된다. 이는, S-지갑(120)이 서명 업데이트를 필요로 하지 않음을 의미한다. 이러한 비감독형 러닝 방안은 랜섬웨어와 같은 위협에 특히 효과적이다. S-지갑(120)은, 접속된 TRDB(110)로부터의 집단 지능을 활용하면서, 다음에 따르는 정보에 대한 기본 차단 서비스를 제공한다.
* 암호화폐 지갑 어드레스 필터링
* URL/URI 필터링
* 데이터 필터링
* 사기 검출 시스템(FDS).
머신 러닝 기술 외에, 인공 지능과 관련된 다른 실행가능한 기술(예를 들어, 퍼지 로직, 딥 러닝 등)을 이용하여, 모든 분산 원장에서 사기 검출 시스템(FDS)을 활성화하고 오용 또는 도난 보고된 거래를 식별할 수 있으므로, 이차 피해를 방지할 수 있다는 점을 인식해야 한다.
다른 일례로, TRDB(110)는, S-지갑(120) 없이 사용될 수 있고/있거나 다른 이용가능한 디지털 지갑과 함께 사용될 수 있다.
분산형 멀웨어 분석 샌드박스 (D- 샌드박스 )
다음 단락은, 본 개시 내용에서 제안된 기술의 차이점 및 이러한 차이점에 연관된 이점을 강조하기 위해 기존의 종래 기술을 참조할 수 있다.
샌드박스는, 애플리케이션이나 호스트를 위험에 빠뜨리지 않고 별도의 가상 머신에서 테스트되지 않거나 확인되지 않은 프로그램 및 코드를 실행하도록 센티넬 프로토콜에서 구현될 수 있는 보안 메커니즘이다. 잠재적 위협은 티켓 시스템을 통해 D-샌드박스에 제출될 수 있으며, 모든 위협은 집단 지능을 사용하여 분석된다. 샌드박스는 더 비용 효율적이고 연산 성능을 더 효율적으로 사용할 것으로 예상된다. 개별 사용자는 가상 머신을 통해 샌드박스를 프로비저닝함으로써 보안 생태계에 기여할 수 있다.
D-샌드박스(126)에는 두 가지 뛰어난 장점이 있다. 첫째, 이것은 상당히 비용 효율적이다. 이것은 분산형 시스템을 통해 확장성을 개선한다. 가상 머신을 실행하기 위한 일반 샌드박스 시스템이 있는 보안 기기의 기능은 제한된다. 고가의 보안 기기라도, 이러한 방식으로 멀웨어를 분석하는 능력이 매우 제한적이었다. 또한, 일반 샌드박스 시스템은, 높은 처리량, 높은 대역폭, 또는 예상보다 높은 사용량과 같은 높은 기능을 보장할 수 없으므로, 매우 불안정할 수 있다. 이로 인해 종종 시스템 성능 저하 및 오작동이 발생하였으며, 이는 사용자 경험을 손상시킬 뿐만 아니라 멀웨어 감염을 초래할 수도 있다.
두 번째 장점은, D-샌드박스(126)가 작업 증명(PoW)에서의 연산 능력 낭비를 최소화하는 것 외에도 더 양호한 보안 시스템을 구축할 수 있다는 점이다. 해시값을 생성하는 연산 능력은 낭비일 수 있다. 센티넬 프로토콜의 네트워크에 참여하는 노드는 자신의 연산 능력을 사용하여 멀웨어를 분석할 수도 있다. 이는 분산형 보안 시스템의 유휴 자원이 필요한 곳에 활용될 수 있음을 의미한다. 개별 사용자는, 또한, 가상 머신을 통해 샌드박스를 프로비저닝하여 전체 보안 에코시스템을 강화함으로써 도움을 줄 수 있다.
센티넬 프로토콜 생태계
다음은 센티넬 프로토콜 생태계의 예를 설명한다.
대화형 협력 프레임워크(IGF(INTERACTIVE COOPERATION FRAMEWORK) 또는 센티넬 포털)
일부 암호화 거래소 플랫폼에는, 초기 시스템 설계 내지 전체 운영에 이르는 보안 전문 지식이 부족하다. 고객 서비스 전문가는, 현재 두 가지 역할을 모두 수행하고 있지만 사이버 보안 전문가가 될 수 없다. 센티넬 프로토콜은, 해당 집단 지능을 활용하는 신뢰할 수 있는 암호화폐 보안 전문가가 운영하는 필수 프레임워크를 제공함으로써 이 문제를 극복한다. 암호화폐 사용자는, 센티넬 프로토콜 커뮤니티에 가입하는 것만으로, 모든 보안 문제에 대한 지식과 지원을 쉽게 얻을 수 있다. 또한, 이들 사용자는 센티넬 프로토콜에 의해 제공되는 보안 솔루션을 배포할 수 있다. 기업과 개인 모두의 비효율성 비용이 감소된다. 이 프레임워크는 암호화폐 세계의 전반적인 보안을 향상시키고 분산화의 기본 원칙을 기반으로 구축된다.
도난방지 시스템
암호화폐를 위한 더 많은 실제 애플리케이션이 매일 구축되지만, 암호화 자산의 무결성을 유효성 검증하기 위한 시스템은 없다. 이는, 해커가 도난당한 암호화 자산을 텀블링 및 혼합(tumbling and mixing)을 통해 분할하는 한 그 자산이 상업 서비스에 대한 지불로서 사용될 수 있음을 의미한다. 신용/직불 카드 회사가 도난당한 신용/직불 카드의 사용을 차단하는 전통적인 금융 시스템과 유사하게, 센티넬 프로토콜은, 도난당한 모든 암호화폐를 추적하고 이 정보를 모든 암호화 서비스 제공업체와 공유한다. 유리하게도, 센티넬 프로토콜을 사용하여 검출된 도난당한 암호화 자산은, 사용 또는 법정 화폐로의 전환이 방지된다. 이는 센티넬 프로토콜을 통해 암호화폐가 규제 제약 하에서 일반 화폐 통화와 유사한 보호를 누릴 수 있음을 의미한다.
변형된 거래 방지(Malformed Transaction Prevention)
신용 사기로 등록된 어드레스 및 파생된 모든 어드레스는 (블록체인의 특성 때문에) 센티넬 프로토콜 커뮤니티 내에서 실시간으로 공유될 수 있다. 센티넬 프로토콜이 적용되는 한, 추가 피해 확산을 방지할 수 있다. 적용가능한 용도 중 하나는, 수천 명의 사람이 짧은 시간 동안 관여하고 어드레스가 변조될 수 있는 초기 코인 공개(ICO) 동안이다. 센티넬 프로토콜이 작동 중이고 해커가 어드레스를 변경하면, 모든 사용자에게는 원래 어드레스와 새로 변경된 어드레스가 자동으로 통지된다. 유리하게도, 센티넬 프로토콜은, 센티넬 프로토콜의 모든 사용자에게 사이버 공격을 알리고 식별된 도메인/IP 어드레스/지갑에 연관된 악성 거래를 중지시키는 체계적인 방법을 제공한다.
예 1: 미식별된 위협 방지(Unidentified Threat Prevention)
해커 말로이(Malloy)는 잘 알려진 암호화폐 온라인 커뮤니티에 소프트웨어를 업로드한다. 그는, VirusTotal 또는 안티바이러스 프로그램과 같은 평판이 좋은 위협 체크 웹사이트에서 검출할 수 없도록 이 소프트웨어를 만들었다. 앨리스(Alice)를 포함한 수십 명의 커뮤니티 사용자는, 일반적인 채굴 소프트웨어라고 생각한 것을 다운로드한다(그러나, 대부분의 사용자는 md5, sha 등을 통해 원본 파일의 무결성을 체크하는 방법을 모른다). 말로이는, 일단 자신의 마이닝 소프트웨어(백도어)가 다운로드된 것을 발견하면, 이것을 정상적인 클린 파일로 교체한다. 그때까지, 사용자 계정은 이미 손상되었으며 모든 정보는 채굴 소프트웨어(백도어)를 사용하여 말로이에 의해 수집 및 도난당했을 것이다. 손상된 및/또는 도난당한 정보는, 지갑의 개인 키의 암호문과 암호화폐 거래소의 자격 증명을 모두 포함할 수 있다. 그러나, 일반 사용자인 앨리스는 사이버 범죄를 조사하는 데 필요한 조사 기술이나 도구를 갖고 있지 않으므로, 시스템이 어떻게 손상되었는지를 확인하기가 어렵다.
이에 비해, 센티넬 프로토콜의 S-지갑(120)을 사용하며 동일한 손상된 채굴 소프트웨어를 다운로드하는 온라인 커뮤니티 사용자인 밥(Bob)은, 자신의 정보를 도난당하지 않고/않거나 손상시키지 않는다. 손상된 채굴 소프트웨어를 다운로드한 후, S-지갑(120) 내의 머신 러닝 엔진(124)은 다운로드된 파일이 매우 의심스럽다는 것을 검출한다. 머신 러닝 엔진(124)은, 파일이 알려진 공격으로 분류되지 않았더라도 및/또는 파일이 지금까지 어떠한 안티바이러스 소프트웨어에 의해서도 검출되지 않았더라도, 다운로드된 파일의 실행을 차단한다. 파일 실행이 차단되는 즉시, 해당 정보는 센티넬 프로토콜에 자동으로 제출된다. 이어서, 신뢰할 수 있는 보안 전문가 그룹인 센티넬(150)이 위협의 근본 원인을 분석한다. 이렇게 분석된 정보는, 위협 평판 데이터베이스(TRDB; 110)에 등록되며, 파일이 원래 발견된 온라인 커뮤니티에도 보고된다. 타임스탬프와 업로더의 더욱 자세한 분석을 통해, 말로이는 해커로 식별된다. 한편, 말로이는, 센티넬 프로토콜 데이터베이스의 실시간 방어 시스템이 모든 곳에서 사용되므로, 자신의 채굴 소프트웨어를 다른 곳에 배포할 수 없다는 사실을 알고 있다.
예 2: 거래 추적성(Transaction Traceability)
해커 말로이는 많은 사람으로부터 자신이 해킹한 훔친 코인 지갑을 갖고 있다. 그는, 지갑을 현금화하기 전에, 추적을 피하기 위해 (텀블링 및 혼합을 통해) 다수의 서브 어드레스 상에 코인을 배포한다. 이는 암호화폐 지갑의 특성으로 인해 가능하다. 앨리스는 말로이의 희생자 중 한 명이다. 앨리스는, 자신의 코인이 도난당한 것을 알게 되자마자, 이를 센티넬 프로토콜(100)에 보고한다. 센티넬(150)은 사건을 확인하고, 사건 정보를 위협 평판 데이터베이스(TRDB; 110)에 등록한다. 센티넬 프로토콜(100)은 등록된 원래 어드레스로부터 파생된 모든 서브 어드레스를 자동으로 추적한다. 이것은 센티넬 프로토콜(100)을 통합한 거래소를 포함한 모든 암호화 서비스에 공유된다. 말로이가 자신의 코인을 변환하려고 하면, 미리 통지받은 거래소 시스템은, 우선순위가 높은 경고를 수신하고, 해커 말로이가 훔친 코인을 사용할 수 있는 어떠한 기회라도 차단한다.
다른 나라들의 현재 사법 시스템이 국경을 넘어 일관되지 않으므로, 앨리스가 동전을 되찾기는 쉽지 않을 것이다. 앨리스는, 자신의 사례, 및 센티넬 프로토콜이 전 세계적으로 더 많이 존재하기를 바라며 센티넬 프로토콜을 사용하는 이점을 적극적으로 홍보하기 시작한다. 언젠가는, 센티넬 프로토콜이 해킹을 신고하기 위해 인터폴이 요구하는 복잡한 문서 및 법적 아이덴티티 확인을 대체하도록 영향력을 행사할 수 있다.
도 2는 블록체인용 보안 지능 플랫폼(SIPB)(예를 들어, 도 1의 참조번호 100)에 대한 프로세스 흐름의 일례를 도시한다. 프로세스 흐름은, 일반 사용자가 TRDB(예를 들어, 도 1의 110), ML 엔진(예를 들어, 도 1의 124), D-샌드박스(예를 들어, 도 1의 126)를 사용하여 자동보고 및 수동보고를 통해 사이버 보안을 개선하는 방법을 예시한다.
사용자가 자신의 장치에 S-지갑(엔드포인트 보안 애플리케이션 및/또는 암호화폐 지갑으로서 기능함)을 설치한 경우, 사용자는 자동보고(AR) 및/또는 수동보고(MR) 기능을 호출할 수 있다. 그러나, 사용자가 자신의 장치에 S-지갑을 설치하지 않았더라도, 사용자는 MR을 통해 SIPB와 상호작용할 수 있다. 이것은 SIPB가 S-지갑과 함께 독점적으로 사용되는 것으로 제한되지 않음을 의미한다.
프로세스 흐름에서, 보안 지갑(S-지갑으로 제한되지 않음)의 감시 중 링크 또는 리다이렉션을 통해 도메인, url, 암호화폐 지갑 어드레스, 파일 다운로드 등을 시도하면, 다음에 따르는 사항들 중 하나가 발생할 수 있다.
자동보고(Auto Report, AR)
자동보고 기능은 알려지지 않은 위협 분석을 최적화하기 위한 지능 프레임워크이다.
도 2를 참조하면, AR 프로세스 중에 다음 단계들이 수행된다.
1. 질의(S201): 사용자는 보고된 정보의 잠재적 신용 사기/유해에 대한 조사 요청을 위협 DB(즉, TRDB)(110)에 전송한다. 보고된 정보는, 사용자 데이터(130)로부터 자동으로 검색되며, 도메인, URL, 암호화폐 지갑 어드레스, 또는 URL을 통해 다운로드된 파일의 형태일 수 있다.
2. TRDB로부터의 응답(S202): 단계 S201의 질의에 응답하여, 위협 DB(110)는 TRDB에 등록된 정보의 데이터 필드를 제공한다. 예를 들어, 리턴된 데이터는, 보고된 도메인, URL, 다운로드된 파일의 암호화폐 지갑 어드레스가 TRDB에 기록되었는지 여부를 나타낼 수 있다(예를 들어, 화이트리스트, 블랙리스트, 그레이리스트). 이 예에서, "O" 값은, 보고된 정보가 TRDB에 기록되지 않았음을 나타내며, 추가 조사가 필요하다. 이는 S202에서 "O" 값이 수신되면 프로세스가 S203으로 진행됨을 의미한다.
3. ML 엔진에 요청(S203): 질의된 어드레스가 신용 사기/유해로 식별되면 (즉, TRDB의 블랙리스트) 이것은 센티넬 프로토콜에 따라 차단된다. 질의된 어드레스가 새로운 위협으로 식별되지 않더라도, 분석을 위해 파일(즉, 보고된 정보의 관련 콘텐츠)이 다운로드된다. 유리하게, TRDB(110)의 데이터는 정기적으로 재검증된다. 예를 들어, 보고된 정보가 TRDB(110)에 블랙리스트로 기록되어 있고 6개월 전에 마지막으로 검증된 경우, ML 엔진은, 보고된 정보가 블랙리스트에 남아 있는지 여부를 결정하도록 트리거될 수 있다. 사용자 장치의 S-지갑(120)은, 다운로드된 파일이 실행되기 전에 다운로드된 파일이 의심스러운지 여부를 분석하기 위한 요청을 ML 엔진(124)에 전송하도록 구성될 수 있다.
4. 추가 검사를 위한 요청/ML 엔진으로부터의 응답(S204): ML 엔진(124)은, S-지갑(120)에 연관된 관련된 노드 내에서 다운로드된 파일 또는 프로세스의 의심스러운 동작을 분석한 후, 다운로드된 파일 또는 프로세스를 알려지지 않은 위협(들)으로 분류하고, 이들을 실행하지 않도록 차단한다. 즉, ML 엔진(124)은, 다운로드된 파일이 의심스럽다고 결정하면, ML 엔진(124)에 의해 S-지갑(120)에 할당된 값을 리턴하여 추가 검사를 트리거한다.
추가 검사는 D-샌드박스(126) 및/또는 센티넬(150)에 의한 분석을 통해 수행될 수 있다. S-지갑(120)은, 예를 들어, S-지갑의 설정을 통해 이러한 검출된 정보를 보고하기 위해 사용자의 허가를 구하도록 구성될 수 있다는 점을 이해해야 한다. 이는, S-지갑에 대해 AR 기능이 활성화된 경우에도, ML 엔진(124)이 센티넬 프로토콜을 통해 검출된 임의의 위협을 보고하기 전에 사용자의 승인을 요청하도록 설정될 수 있음을 의미한다. 일례로, ML 엔진(124)은 팝업 창에 의해 사용자에게 승인을 요청하도록 구성된다.
5. 제출(S205): 일단 S-지갑(120)이 알려지지 않은 위협(들)에 대한 추가 검사를 트리거하기 위한 응답을 수신하면, ML 엔진(124)으로부터의 요청이 샌드박싱을 위해 분산형 샌드박스(예를 들어, D-샌드박스(126))에 전송된다. 예를 들어 S-지갑(120)이 예컨대 S-지갑 설정에서 제출 옵션(선택적 온/오프)을 통해 S204에서 사용자로부터의 승인을 요청하도록 구성된 경우, S-지갑(120)은, (의심스러운 파일을 포함하는) 위협 정보와 함께 요청을 샌드박싱을 위한 분산형 샌드박스에 전송하기 전에, 이러한 제출 옵션이 활성화되어 있는지 여부를 체크한다.
분산형 샌드박스에 의한 분석 결과는 S206에서 S-지갑(120)으로 다시 전송된다. 이러한 결과는 사용자에 의해 검토될 수 있다.
6. 센티넬로의 AR 요청(S207): 자동보고 사례가 생성되어 대화형 협력 프레임워크(IGF) 대시보드(즉, 도 1의 160)를 통해 센티넬(150)에 공유된다. 자동보고 사례는 D-샌드박스(126)로부터 요청을 수신한 후에 생성된다.
7. 분석 응답: 센티넬은, 샌드박스, 분산형 샌드박스, 또는 추가 도구를 사용하여 사용자가 보고한 위협을 분석한다. 센티넬(150)이 보고된 위협의 근본 원인을 분석한 후, 분석 결과는 위협 평판 데이터베이스(TRDB; 110)에 등록된다. 분석 결과가 알려지지 않은 위협이 실제로 악성이라고 결정되면, 악성 파일이 원래 검출된 온라인 커뮤니티는 경고를 받을 수 있다. 분석 결과(또는 분석된 정보)는, TRDB(110)의 블랙리스트에 추가하기 위한 표시자 및/또는 TRDB(110)의 화이트리스트에 추가하기 위한 표시자를 포함할 수 있다.
8. 업데이트: 센티넬에 의한 분석 결과를 포함한 업데이트된 위협 정보를 위협 DB(110)에 전송한다(S208). 업데이트된 위협 정보는, 업데이트된 위협 정보를 TRDB(110)에 블록체인의 데이터 블록으로서 등록하기 전에 유효성 검증(예를 들어, 분석 결과는 센티넬의 개인 키로 서명되어야 함)을 받을 수 있다.
또한, 도메인 정보를 감시 및/또는 TRDB와 비교하여 악성 데이터의 검출을 개선할 수 있다.
도 2에 예시된 단계들은 순차적일 필요가 없다는 점을 이해해야 한다. 예를 들어, 일례로, AR 요청은, 단계 S202(즉, TRDB(110)로부터) 또는 단계 S204(즉, ML 엔진(124)으로부터) 직후에 실행되도록 배치될 수 있다. 이러한 예에서, AR 사례가 생성된 후에 D-샌드박스에 의한 추가 검사를 위한 개시 요청이 센티넬(150)에 의해 트리거될 수 있다. 다른 일례로, 단계 S204도 생략할 수 있고, D-샌드박스(126)에 의한 추가 검사를 트리거하기 위한 요청이 ML 엔진(124)으로부터 직접 전송될 수 있다.
수동 보고(Manual Report, MR)
도 2를 참조하면, 사용자는 다음 단계들을 통해 신용 사기 정보를 수동으로 보고할 수도 있다.
1. MR 제출(S211): 도메인 정보, 신용 사기 URL, 신용 사기 어드레스, 및 의심스러운 정보의 파일은, 각 사용자에 연관된 S-지갑의 보고 기능을 사용하여 센티넬(150)에 직접 보고될 수 있다.
2. 업데이트(S212): 센티넬이 신용 사기 정보를 검증한 후, 업데이트된 위협 정보가 위협 DB(110)에 전송된다. 센티넬은, 샌드박스 또는 분산형 샌드박스 또는 추가 도구를/사용하여 사용자가 보고한 알려지지 않은 위협을 분석할 수 있다. 업데이트된 위협 정보는, TRDB(110)의 블랙리스트에 추가하기 위한 표시자 및/또는 TRDB(110)의 화이트리스트에 추가하기 위한 표시자를 포함할 수 있다. 업데이트된 위협 정보는, 업데이트된 위협 정보를 TRDB(110)에 블록체인의 데이터 블록으로서 등록하기 전에 유효성 검증(예를 들어, 분석 결과는 센티넬의 개인 키로 서명되어야 함)을 받을 수 있다.
합의 메커니즘(지분 증명)
작업 증명(PoW)의 기본 메커니즘은, 결과가 채굴을 통해 주어진 대상 난이도의 근사치에 도달할 때 블록 생성 권한 및 그에 상응하는 이점을 제공한다. 결과를 찾는 프로세스는 시행착오를 수반하는 광범위한 연산 작업을 필요로 하므로, 소수를 제외한 모든 사람이 이를 달성하는 것은 어렵다. 따라서, 이러한 어려운 프로세스를 거친 사람이 대다수를 대표하는 위임자로 될 수 있다. 문제는, 이러한 위임자를 찾는 프로세스에서 막대한 전력 낭비가 비효율적이라는 점이다. 그 결과, 합의를 개선할 수 있는 다른 방법에 대한 논의가 있었다. 한 구성에서는, 지분 증명(PoS)으로 알려진 보유 지분의 양만큼 위임 확률을 증가시키는 알고리즘이 있다.
본 개시 내용의 일례로, 사례 유효성 검증은 프리 센티넬들(Pre-Sentinel) 간에 발생하며, 여기서 한 프리 센티넬로부터의 데이터는 (자격 있는 사이버 보안 전문가를 포함하는) 보안 팀, 예를 들어, 웁살라 시큐리티의 보안 팀에 의해 이중 체크된다. 업데이트된 위협 정보를 TRDB(예를 들어, 도 1의 110)에 블록체인의 데이터 블록으로서 등록하기 전에 사례 유효성 검증이 필요하다. 프리 센티넬은, TRDB에 기여하고 자신의 신뢰성 및/또는 신인성(dependability)을 나타내는 평판 점수를 개선하도록 노력하는 보안 전문가로서 정의될 수 있다. 이러한 평판 점수는 센티넬 프로토콜 시스템에서 사용자 참조용으로 사용될 수 있다.
센티넬 프로토콜의 합의는, 대니얼 라리머(Daniel Larimer)가 발명한 BitShares로부터 도입된 위임 지분 증명(DPoS) 아이디어를 개선한다. 웁살라 시큐리티에 의해 위임된 센티넬은, 암호화폐 거래소의 보안 팀, 글로벌 사이버 보안 연구 회사, 또는 화이트 해커 그룹, 또는 개별 화이트 해커 그룹과 같이 필요한 자격을 갖춘 증명된 기관들 또는 개인들의 그룹이다. 모든 위임자는 자신의 지위와 경험을 입증한 전문가이다. 따라서, 위임자의 악성 의도의 위험이 크게 줄어들고, 합의가 최적화될 수 있다.
TRDB에서 데이터 무결성을 유지하기 위해, 센티넬 프로토콜 합의에 점수 평판이 도입된다. 즉, 평판 점수가 높을수록 센티넬이나 프리 센티넬이 더 높은 순위를 받는다.
일례로, 평판 점수는 센티넬 포인트(SP)에 의해 측정되며, 여기서 UPP는 유통 통화이다. 센티넬 포인트는 센티넬 및/또는 프리 센티넬의 구성원으로서 활동해야만 취득될 수 있다. 예를 들어, 센티넬(150)은, 도 1의 S-지갑(120)에 의해 제공되는 자동 보고(AR) 기능과 수동 보고(MR) 기능을 통해 등록된 사례를 분석하고, 관련 정보를 TRDB에 기록하고, TRDB의 이러한 데이터는 다양한 업계의 많은 생태계에서 공유될 수 있다.
센티넬 및/또는 프리 센티넬 구성원의 평판 점수를 정량화하는 다른 일례는, 센티넬 및/또는 프리 센티넬의 성과를 각각 기반으로 하는 것으로서, 사용자는 실제로 자신의 평판에 투표할 수 있다. 시스템은, 센티넬 프로토콜에서 보호 증명(PoP; Proof of Protection)으로서 정의된 평판 점수를 취득함으로써 위임된다. 부정직한 센티넬의 행동이 시빌 공격(Sybil attack ) 또는 체인 포킹(chain forking)처럼 해를 입히려는 경우, 사용자는 처벌로 자신의 평판 점수를 잃게 된다. 이더리움의 슬래셔와 마찬가지로, 이는, 대표자들이 명성과 자격을 모두 잃게 될 위협을 받으므로, "잃을 게 없는"(nothing at stake) 문제를 제거한다.
평판 시스템, 특히, 이 구조의 장점은, 개인이 자신의 전문 분야에서 신뢰의 대표자이기 때문에 나쁜 행위자로 되는 것이 거의 불가능하다는 점이다. 기술적으로, 이러한 신뢰 구조에서는, 많은 수의 위임된 센티넬이 불필요하며, 이는 합의를 확보하기 위한 무작위성을 높이고 불필요한 지연을 추가하도록 기능할 뿐이다. 따라서, 센티넬 프로토콜의 합의 구조의 일례에서는, 거래의 유효성 검증, 블록 생성, 및 TRDB 업데이트를 담당하는 센티넬이 7개만 선택된 그룹이 있다. 평판 순위에 따라, 도 3을 참조하면, 한 예에서 총 10개의 센티넬(A-J)이 선택되었으며, 7개는 활성으로 지정되고 3개는 대기로 지정되어 있다. 도 3에서, 대기로 지정된 3개의 센티넬은 센티넬(A, G 및 J)이다. 이러한 3개의 센티넬은, 네트워크 레이턴시와 지연을 줄이는 데 필요한 경우가 아니면, 대기 상태로 유지된다. 본 예에서는 선택된 수의 센티넬만이 제안되지만, 다른 예에서는 커뮤니티(즉, 블록체인 네트워크)가 확장됨에 따라 많은 수의 위임된 센티넬이 제공될 수 있음을 이해할 수 있다. 다른 일례로, 미리 정의된 영역 또는 커뮤니티(지리적으로 정의될 수 있음)를 서비스하는 소규모 센티넬 그룹이 있을 수 있다. PoP 동기식 알고리즘과 비동기식 비잔틴 결함 허용(asynchronous Byzantine Fault Tolerance, BFT)은, 상당한 네트워크 프래그먼트, 대규모 DDOS 공격, 또는 기타 예상치 못한 이벤트가 발생하여 대부분의 센티넬의 통신이 서로 끊어지는 경우에 중복 합의 알고리즘으로서 지원된다.
센티넬 프로토콜의 PoP(Proof of Protection)는, 레이턴시, 확장성, 및 안정성 면에서 간단하고 효율적으로 설계되어 있다.
도 3은 블록체인에서 데이터 블록이 생성되는 때를 결정하는 데 사용되는 고 수준 합의 다이어그램(high level consensus diagram)의 일례를 도시한다. 도 3에 설명된 보호 증명(PoP) 합의 다이어그램은 다음에 따르는 구성요소들을 포함한다.
* 10개의 위임된 평판 센티넬은 도 3에 도시된 역 피라미드 구조를 형성한다. 이러한 10개의 위임된 센티넬은, 평판 순위가 가장 높은 센티넬 풀에서 선택된다. 의심의 여지를 없애기 위해, 각각의 위임된 센티넬은 다이어그램에서 개인 그룹에 의해 표시되지만, 각 센티넬은 다른 예에서 개인 또는 조직을 나타낼 수 있다.
* 평판 점수는 개인 그룹의 각 개인 아래에 표시된다. 도 3에서, 점수는 센티넬 프로토콜에 대한 개별 기여에 의해 얻어진 센티넬 포인트를 나타낸다. 예를 들어, 센티넬(E)은 60개의 센티넬 포인트를 보유하고, 센티넬(C)은 80개의 센티넬 포인트를 보유한다.
* A, G, 및 J는 대기 상태로 되는 3개의 엔드포인트 각각에 해당한다. 이들 3개의 엔드포인트(즉, 대기 노드)는 무작위로 지정된다는 점에 주목한다. 이는 이러한 대기 노드가 블록체인의 다음 블록 생성에서 활성화될 수 있음을 의미한다.
* 센티넬(B, C, F, I, H 및 D)에 의해 형성된 육각형의 노드에는 무작위로 블록 생성이 부여된다.
* 역 피라미드 구조의 각각의 작은 삼각형 구조(즉, DGH, DEH, EHI, EFI, FIJ, BDE, BCE, CEF 또는 ABC)는 효율성을 위해 가장 작은 멀티캐스트 그룹에 태그를 지정하여 브로드캐스트를 최소화하기 위한 것이다.
* 7개의 고정 노드를 선택함으로써 합의 프로세스 최소화.
* 'n= 3f+1' 구조에 대하여 구현된 비잔틴 결함 허용(BFT)의 경우, 3개의 대기 노드로 최대 10개의 노드를 운영할 수 있으며, 센티넬(E)의 노드가 마스터로 된다.
* 대기 노드(A, G 및 J)는 서비스 거부(DoS, Denial of Service) 저항 및 고 가용성(high availability)으로 과금된다. 노드(A, G 및 J)는 (안정된 합의를 위해) 피어 노드의 백업을 수행한다. 센티넬은 강력한 네트워크 보안 환경을 구축할 수 있다.
요약하면, 도 3에 예시된 DPOS 합의에 따라, 센티넬 프로토콜은 7개의 센티넬이 해당 블록을 생성하기 전에 사고 데이터를 유효성 검증할 수 있게 한다. 센티넬에 의한 임의의 악성 시도에 대해, 해당 센티넬은 불이익을 받고, 센티넬 포인트를 잃고, 이에 따라 재정적 보상과 평판을 잃게 된다. 이러한 인센티브 및 페널티 구조에 의해, 센티넬은 올바른 유효성 검증을 수행하도록 장려된다.
일례로, 사례 상태는 센티넬 자신이나 다른 센티넬에 의해 수정될 수 있다. 블록체인에 이미 저장된 데이터의 경우, 센티넬만이 블록을 생성할 권한이 있다. 센티넬은, (예를 들어, 센티넬이 실수한 경우) 이전 블록을 덮어쓰고 새로운 블록을 생성할 수 있다. 이는, 사이트의 상태 또는 어드레스 상태인 경우에도 발생한다(예를 들어, 화이트리스트에 있는 어드레스가 나중에 블랙리스트에 있을 수 있다).
센티넬 프로토콜의 인센티브 시스템
센티넬 프로토콜은, 중앙 집중형 지침이나 조직 없이도 적절한 타임프레임 내에 자립형 사이버 보안 생태계를 생성하는 것을 목표로 한다. 효과적인 사이버 보안 생태계는, 상품이나 서비스의 사용을 보상하기 위한 직접적인 수단으로서 교환가능한 암호화폐를 필요로 하며, 또한, 사이버 보안 생태계를 개선하기 위한 개인의 주관적인 기여를 나타내는 독립적인 값을 필요로 한다. 따라서, 센티넬 프로토콜은, 센티넬 프로토콜의 평판의 스테이킹 값(staking value)을 위한 센티넬 포인트(SP) 및 센티넬 프로토콜에 의해 제공되는 상품 및 서비스를 사용하기 위한 유통 암호화폐, 예컨대, UPP(웁살라 토큰; Uppsala Token)를 가지고 있다. UPP 대신, 다른 예에서는 다른 디지털 통화가 센티넬(또는 보안 전문가)에 대한 금전적 보상으로서 사용될 수 있음을 이해해야 한다.
초기 기여자는 더 큰 인센티브를 받으며, 일단 센티넬 프로토콜이 소정 수준의 지능 또는 타임프레임에 도달하면, 초기 기여자에게 혜택을 주도록 상대적 유사한 기여에 대한 UPP 인센티브의 자동 감소가 구현된다. 이러한 인센티브 시스템은, 사이버 보안 전문가의 도움이 필요한 사람 및 전문가(개인 또는 조직)의 참여를 장려하도록 설계되었다.
다음 단락은, 초기 기여자가 더 큰 인센티브를 받을 수 있는 방법을 보여주는 일례를 설명한다.
UPP ( 웁살라 토큰)
* UPP는, 보안 지갑의 고급 보안 기능과 같이 센티넬 프로토콜 생태계에서 제공되는 상품 및 서비스를 위한 통화이다.
* UPP는, 또한, 상세한 사이버 포렌식 서비스, 컨설팅, 취약성 평가, 및/또는 센티넬 프로토콜의 도움이 필요한 기타 활동을 위해 개설된 경우에도 사용될 수 있다.
* 사용료는 카이버 네트워크와 같은 DEX(분산형 거래소) 플랫폼에 의해 스마트 계약으로 수집될 수 있다.
* 한 방식에서는, 초기 단계의 사이버 보안 커뮤니티 구축자를 위해 500,000,000의 UPP를 생성 및 배포할 수 있다.
* 고급 기능 사용료, 사례 처리 수수료, 및/또는 웁살라 시큐리티에 의한 향후 개발로부터 수집된 UPP의 30%는, 비례 체계에 따른 해당 작업에 대한 커뮤니티 기여자에게 보수를 지급하도록 인플레이션에 의해 생성된 UPP와 함께 부여될 수 있다.
* 20개의 타임-베스팅(time-vesting) 전체에 걸쳐, 후술하는 인플레이션 비에 따라, 추가 UPP가 생성될 수 있고, 전술한 바와 같이 보호 증명(PoP)에 의해 통해 센티넬 프로토콜 생태계를 더 나은 곳으로 만드는 기여자에게 배포될 수 있다.
* 센티넬 프로토콜 생태계에 기여하는 초기 참여자 또는 초기 센티넬에 인센티브를 제공하기 위해, 초기 인플레이션 비를 3% 내지 7%로 설정한다. 후속하여, 인플레이션 비가 (거의) 0%에 도달할 때까지 각 라운드마다 인센티브의 대수 감분 퍼센트(logarithmic decrement percentage)가 감소될 수 있다.
* 생성된 총 센티넬 포인트가, 더 빨리 도달하는, 목표값 또는 소정 주의 타임프레임에 도달하면, 각 베스팅 라운드가 실행될 수 있다.
* 한 구성에서는, 초기 UPP 공급의 15%는 웁살라 시큐리티를 위해 예약되고, 초기 UPP 공급 판매 수익의 15%는 비즈니스 개발, 개발 자금, 법률 자금, 자문 인센티브, 자금 등을 필요로 하는 기타 조직 활동을 위해 예약되고, 초기 UPP 공급의 2%는 자문 인센티브를 위해 예약되고, 초기 UPP 공급의 8%는 예상치 못한 비즈니스 활동을 위해 예약된다.
* 한 구성에서는, 나머지 UPP(즉, 초기 UPP 공급의 60%)는 센티넬 프로토콜 초기 기여자, 사용자, 기여자, 지지자 등을 위해 시장에 배포된다.
다음 단락에서는 UPP와 교환하여 센티넬 포인트를 어떻게 받을 수 있는지에 대한 일례를 설명한다.
센티넬 포인트
보호 증명(PoP)에 의해서만 획득될 수 있다.
POP는, 실제 신용 사기꾼의 어드레스 보고, IP, 웹사이트, 보고서의 유효성 검증, 사고 사례 해결 등을 포함하되 이에 한정되지 않는 다양한 사이버 보안 활동을 포함한다.
합법적인 보고서 유효성 검증은 센티넬에 의해 수행된다.
S-지갑 소유자는 D-샌드박스 연산에 의해 PoP를 수행할 수 있다.
센티넬 프로토콜 커뮤니티에 대한 기타 간접적 기여는, 사이버 보안 문제에 대해 대중에게 알리기 위한 기사 생성 또는 다른 언어로의 기사 번역을 포함한다.
센티넬은 보고서 분석 및 사용자의 평판 투표에 따라 센티넬 포인트를 취득한다.
센티넬 포인트 보유자는 전술한 UPP 생성의 베스팅 혜택(vesting benefit)을 받는다. 베스팅 금액은, 커뮤니티를 위해 수행된 POP를 통해 생성된 총 센티넬 포인트와 관련하여 각 엔티티가 보유하는 센티넬 포인트에 비례한다. 자동화된 교환 프로세스를 적용할 수 있다.
예시적인 한 기술에서, 센티넬 프로토콜은 웹 브라우저(예를 들어, Chrome, Mozilla Firefox 등)를 위한 추가 확장 기능으로서 제공될 수 있다.
확장에는 다음과 같은 기능이 있을 수 있다.
* 위협 평판 데이터베이스의 화이트리스트 및 블랙리스트 정보를 이용하여, 사용자는 화이트리스트 사이트를 방문할 때 작은 팝업 표시자에 의해 알림을 받는다. 마찬가지로, 사용자는 블랙리스트 사이트를 방문할 때 오버레이에 의해 잠재적으로 속이는 웹사이트에 방문하였다는 알림을 받는다. 또한, 사용자는, 희생자를 피싱 사이트로 유도하도록 공격자가 사용하는 것으로 알려진 Puny 코드를 이용하는 사이트에 방문할 때도 알림을 받을 수 있다.
* 화이트리스트 및 블랙리스트 암호화 어드레스에 대한 검색 기능.
* 최종 사용자는 확장 기능을 사용하여 의심스러운 사이트를 신고할 수 있다.
일례로, 일단 사용자가 자신의 웹 브라우저(또는 해당 API)에 대한 센티넬 프로토콜 애드온 확장 기능을 설치하면, 이제 자신이 상호작용할 수 있는 암호화 지갑 어드레스 및 웹 사이트를 검증하는 자동화 수단이 존재한다.
예를 들어, 거래소가 지갑 어드레스로부터 암호화 자산을 받은 후에, 거래소는 관련 API를 사용하여 TRDB에 질의하여 지갑 어드레스가 TRDB에서 블랙리스트에 올랐는지 여부를 체크할 수 있다. 그 어드레스가 블랙리스트에 등록된 경우, 이는 관련 자금이 신용 사기나 해킹과 같은 불법적인 이득에서 나온 것임을 나타낼 수 있다. 다른 일 구현예에서, 입력된 암호화 어드레스 또는 ICO 사이트는 강조 표시될 수 있으며, API를 사용하여 TRDB에 질의한 후, 입력된 암호화 어드레스의 강조 색상은 화이트리스트 또는 블랙리스트 또는 알 수 없음을 나타내도록 변경될 수 있다. 일례로, 도 16a를 참조하면, 악성 암호화 어드레스(즉, 블랙리스트)가 빨간색으로 강조 표시되어 있다. 또한, 경고는, 강조 표시된 암호화 어드레스를 오버레이하여 거래가 위험하다는 것을 사용자에게 나타낼 수 있다. 다른 일례로, 도 16b를 참조하면, 안전한 암호화 어드레스(즉, 화이트리스트)는 녹색으로 강조 표시되고, 알 수 없는 암호화 어드레스(즉, 알 수 없음)는 강조 표시되지 않는다(도 16a 및 도 16b에 도시되지 않는다). 또한, 경고는 강조 표시된 암호화 어드레스를 오버레이하여 질의된 암호화 어드레스가 안전함을 사용자에게 나타낼 수 있다. 강조 표시된 암호화 어드레스를 클릭하면 사용자가 포털의 표시자 세부 화면으로 리다이렉션되도록 API를 구성할 수도 있다.
센티넬 프로토콜은 피싱 및 명의도용 검출 시스템에도 사용될 수 있다. 한 방식에서는, TRDB를 피싱 및 명의도용 검출 시스템(트위터 크롤러 시스템과 상호 교환적으로 사용됨)과 연결하는 API를 생성할 수 있다. 또한, 피싱 및 명의도용 검출 시스템에서 머신 러닝을 사용하여, 검출된 사이트로부터 패턴을 분석하고 수집하여 피싱 및 명의도용 검출 시스템의 검출 알고리즘을 개선할 수 있다. 피싱 및 명의도용 검출 시스템은, 다른 적법한 트위터(또는 다른 소셜 네트워킹)를 명의도용하는 트위터 (또는 다른 소셜 네트워킹) 계정을 자동 검출하고 플래그 표시하도록 센티넬 프로토콜에 대한 애드온 기능 또는 독립형 기능(예를 들어, 센티넬 프로토콜에 기초하여 블록체인 네트워크에 대한 링크를 갖는 제삼자 애플리케이션)일 수 있다. 피싱 및 명의도용 검출 시스템은, 이러한 명의도용된 계정을 사용하여 트위트되는 경품 사기를 검출하도록 구성될 수 있다.
예를 들어, 센티넬 프로토콜에 대한 애드온 기능으로서 구현된 경우, 센티넬 프로토콜을 사용하여 트위터 계정의 트위터 핸들을 체크하여 사용자의 아이덴티티를 인증할 수 있다. 도 4는 합법적인 트위터 계정 A를 합법적인 트위터 계정 A를 명의도용하도록 생성된 가짜 트위터 계정 B와 비교한다. 도 4에서는 트위터 계정의 프로파일명이 고유하지 않지만 각 트위터 계정의 트위터 핸들이 고유하다는 것을 명백히 알 수 있다. 특히, 도 4의 트위터 계정 A와 B의 프로파일명은 "CZ_Binance"이다. 트위터 계정 A의 트위터 핸들은, "@cz_binaance"인 계정 B의 트위터 핸들과 비교할 때 "@cz binance"이다.
따라서, (도 5a와 도 5b에 도시된 바와 같이) 피싱 링크를 이용하거나 지갑 어드레스를 삽입하여 주요 암호화 영향 또는 주요 암호화 영향에 의한 트위트에 대한 응답을 명의도용함으로써, 악성 행위자가 피싱 캠페인을 수행할 수 있다. 주요 암호화 영향은 암호화 스타트업 CEO를 지칭할 수 있으며, 소셜 미디어는 암호화 기술 또는 블록체인 기술 등의 분야에서 저명한 임의의 인물에 영향을 미친다.
일례로, 도 5a를 참조하면, 트위터 핸들(504)에 의해 식별된 가짜 트위터 계정은, 트위터 핸들(502)에 의해 식별될 수 있는 합법적 계정에 응답하고 있다. 피싱 캠페인(505)에 대한 링크(긴 점선으로 그려진 상자로 표시됨)는 가짜 트위터 계정의 응답에 포함된다. 가짜 트위터 계정(즉, CZ)의 프로파일명이 합법적인 트위터 계정(즉, CZ Binance)과 유사한 프로파일명을 가지고 있으므로, 독자는, 이것이 자신이 신뢰하는 합법적인 계정의 진짜 게시물이라고 생각하면서 실수로 피싱 링크로 리다이렉션되거나 피싱 링크를 클릭할 수 있다.
다른 일례로, 도 5b를 참조하면, 가짜 트위터 계정이 트위터 핸들(502)에 의해 식별될 수 있는 합법적인 계정에 응답하고 있다. 그러나, 응답 체인의 첫 번째 게시물(506)에는, 피싱 캠페인에 대한 링크가 없다. 이 예에서, 가짜 트위터 계정은 두 번째 게시물(507)이 있는 가짜 트위터 계정의 첫 번째 게시물(506)로부터 계속된다. 두 번째 게시물(507)에는 피싱 캠페인(505)(긴 점선으로 그려진 상자로 표시됨)에 대한 링크가 있다. 가짜 트위터 계정의 프로파일명은 합법적인 트위터 계정(예를 들어, Justin Sun)과 동일한 프로파일명을 가지고 있으므로, 독자는, 이것이 자신이 신뢰하는 합법적인 계정의 진짜 게시물이라고 생각하면서 실수로 피싱 링크로 리다이렉션되거나 피싱 링크를 클릭할 수 있다. 도 5a 및 도 5b에 도시된 피싱 캠페인(505)은 예시를 위한 것이며, 그 내용의 재현성은 본 예를 이해하는 데 중요하지 않다는 점에 주목한다.
도 5a의 가짜 트위터 계정의 응답 게시물과 달리, 고유한 트위터 핸들은 도 5b의 가짜 트위터 계정의 두 번째 게시물(507)에 표시되지 않는다. 이는, 도 6b에 도시된 바와 같이, 도 5b의 예에서 가짜 트위터 계정의 악성 행위자가 공간 또는 한글 필러를 사용하여 고유한 트위터 핸들(504)을 화면 밖으로 밀어냈기 때문이다. 이는, 도 5b의 합법적인 트위터 계정이 프로파일명과 고유한 트위터 핸들(502) 사이에 공백이나 한글 필러를 사용하지 않은 도 6a와 대조적이다.
다른 일례로, 도 7을 참조하면, 악성 행위자는 자신의 트위터 핸들(604) 및/또는 프로파일명(603)에서 문자를 생략한다. 이 예에서, 악성 행위자는, 자신의 트위터 핸들(604) 및/또는 프로파일명(603)에 있는 합법적인 트위터 계정 소유자의 실제 프로파일명과 시각적으로 유사한 문자를 사용할 수도 있다. 합법적인 트위터 계정의 프로파일명(601)과 고유 핸들(602)은 비교를 위해 도 6d에 도시되어 있다. 프로파일명(601) 옆에 위치하는 보안 배지(605)(파란색)는, 계정이 진본임을 나타내도록 트위터 서비스 공급자에 의해 제공된 것이다. 이 예에서, 합법적인 트위터 계정과 비교할 때, 프로파일명(603)에서 문자 "I"가 누락되어 있고, "n" 대신 "m"과 같이 시각적으로 유사한 문자가 트위터에 사용되고 있다는 점이 분명하다.
유리하게는, 합법적인 트위터 계정을 인증하고/하거나 일반 대중이 가짜 트위터 계정과 합법적인 트위터 계정을 구별할 수 있도록 TRDB(예를 들어, 도 1의 110)를 피싱 및 명의도용 검출 시스템과 연결하는 API를 생성할 수 있다. API는 python 스크립팅, diango 스크립팅, 또는 PostgreSQL 스크립팅의 형태일 수 있다.
일례로, 피싱 및 명의도용 검출 시스템을 사용하여, 특정 트위터 계정(예를 들어, 암호화 인플루언서)에 대한 트위트 답글을 크롤링하여 다음 중 하나 이상을 검출할 수 있다.
* 명의도용 트위터 계정
* 악성 트위트
* 피싱 링크
* 악성 행위자의 지갑 어드레스.
도 8a는, 트위터 크롤러 시스템을 구현할 수 있는 방법에 대한 일례를 도시한다. 트위터 크롤러 시스템은 API(Application Programming Interface)를 통해 그 시스템을 사용하려는 모든 사용자에게 공유될 수 있다.
단계 S802에서, 트위터 크롤러 시스템은, 사용자 또는 웁살라 시큐리티의 구성원이 감시할 암호화 인플루언서, 악성 트위트에서 공통적인 키워드, 및/또는 피싱 사이트의 html 코드에서 공통적인 패턴을 추가할 수 있도록 구성된다. 다른 일례로, 해당 API를 사용함으로써 센티넬 프로토콜(백엔드)에 의해 자동으로 아이덴티티 체크가 수행될 수 있다. 이러한 단계 S802는 다음에 따르는 하위 단계들을 포함할 수 있다.
(a) 감시할 트위터 계정을 입력하며, 예를 들어, 주요 암호화 인플루언서의 트위터 계정을 입력한다. 주요 암호화 인플루언서는, 암호화 스타트업 CEO, 소셜 미디어 인플루언서, 암호화 기술 또는 블록체인 기술 분야의 저명한 인물 등을 지칭할 수 있다.
(b) 악성 트위트에서 흔히 볼 수 있는 키워드, 예를 들어, "에어드롭 지갑", "지갑 어드레스" 등을 입력한다. TRDB에는, 사용자가 키워드를 삭제, 편집, 또는 추가할 수 있는 키워드 관리 기능이 제공될 수 있다.
(c) 피싱 사이트에 공통적인 (HTML 코드의) 패턴을 입력한다. TRDB에는, 사용자가 패턴을 삭제, 편집, 또는 추가할 수 있는 패턴 관리 기능이 제공될 수 있다.
단계 S804에서, 트위터 크롤러 시스템은 단계 S802에서 사용자 또는 센티넬에 의해 입력된 검색 설정을 검색한다.
일례로, 단계 S806에서, 감시되는 모든 인플루언서에 대한 모든 트위트 응답이 단계 S806에서 검색된다. 감시되는 각 트위트 계정에는 "lastRetrievedID"라는 파라미터가 할당되며, 여기서 "lastRetrievedID"는 리턴된 모든 트위트 중 가장 최근에 검색된 트위트의 트위트 ID라는 점에 주목한다. 이러한 정보는 분석을 용이하게 하도록 TRDB에 저장될 수 있다.
일례로, 도 8b를 참조하면, 아래 커맨드와 같은 Python-twitter API를 사용하여 정기적으로 (폴링을 통해) 트위트 응답을 검색할 수 있다.
Figure 112020142427231-pct00001
Figure 112020142427231-pct00002
(도 8b 참조).
커맨드의 재귀는 GetSearch가 값 0을 리턴할 때까지 반복된다는 점에 주목한다. 결과적으로, since_id는 특정된 ID보다 더 최신인 ID로 결과를 리턴한다. 위 커맨드에서, 특정된 ID가 lastRetreived ID로서 할당된 경우, 이 커맨드는 lastRetreived ID에 연관된 트위트 뒤에 다음 100개의 트위트를 리턴한다.
단계 S808에서, 트위터 크롤러 시스템은 명의도용 체크를 수행하도록 구성된다. 트위터 사용자의 아이덴티티는 다음 조건들 중 하나 이상을 체크함으로써 인증될 수 있다.
* 고유한 트위터 핸들을 화면 밖으로 밀어내도록 공백이나 한글 필러 등의 사용(예를 들어, 도 6b 참조)
* 트위터 핸들 및/또는 프로파일명의 문자 누락(예를 들어, 도 6d 참조)
* 트위터 핸들 및/또는 프로파일명에 시각적으로 유사한 문자의 사용(예를 들어, 도 6d 참조)
* 트위터 핸들 및/또는 프로파일명에 영어 알파벳처럼 보이는 키릴/러시아 문자와 같은 특수 문자의 사용(예를 들어, 도 8d 참조).
명의도용 체크 프로세스(즉, S808) 중에, 트위터 크롤러 시스템은, 한글 필러를 공백으로 대체하고 감시 중인 트위터 계정의 프로파일명의 끝에서부터 모든 공백을 제거하도록 구성된다. 이러한 구현은, 트위터 핸들이 프로파일명 바로 뒤에 위치하도록 하며, 즉, 도 6b에 표시된 공백 문제를 제거한다.
이어서, TRDB에 추가된 모든 인플루언서의 핸들 및/또는 프로파일명에 대해 조사 중인 핸들 및/또는 프로파일명 간에 유사성 테스트를 수행한다. 감시할 인플루언서는 통상적으로 웁살라 시큐리티에 의해 TRDB에 추가된다. 다른 수정예에서, 사용자는 자신의 트위터 계정이 감시되도록 SIPB에 요청을 제출할 수 있다.
유사성 테스트의 일례에서, Levenshtein 거리 알고리즘(예를 들어, 도 8c 참조)을 두 개의 문자열 간에 수행하여 두 개의 문자열이 얼마나 다른지 비교할 수 있으며, 여기서 제1 문자열은 감시되는 트위트 계정의 핸들 또는 프로파일명이고, 제2 문자열은 TRDB에 추가된 모든 인플루언서의 핸들 또는 프로파일명 중 하나이다. Levenshtein 거리 알고리즘은, 제1 문자열을 제2 문자열로 변환하는 데 필요한 최소 연산 수를 기반으로 연산된 Levenshtein 거리 점수를 리턴하며, 이러한 연산은 삭제, 추가, 및 교체를 포함한다. 두 개의 문자열 간의 점수가 낮을수록, 두 개의 문자열이 더 유사하다. 편집 거리의 다른 방안(예를 들어, Damerau-Levenshtein 거리, Wagner-Fischer 알고리즘)을 이용하여, 두 개의 문자열이 얼마나 유사한지를 결정할 수 있음을 인식해야 한다. 연산된 점수가 임계값보다 작으면, 감시 중인 계정은 잠재적인 명의도용자로서 플래그 표시된다.
도 8c를 참조하면, 응답자 핸들 "xPEYT0"은 인플루언서 핸들 "PEYT0"과 비교된다. 응답자 핸들을 인플루언서 핸들로 변환하려면, 두 개의 연산이 필요함을 알 수 있다. 문자 "x"를 삭제하려면 삭제 작업이 필요하고, 문자 "0"을 "O"로 대체하려면 대체 연산이 필요하다. 결과적으로, 연산된 Levenshtein 거리 점수는 2이다.
유사성 테스트의 다른 일례에서, 핸들 또는 프로파일명의 특수 문자(예를 들어, 키릴 문자)의 수를 분석을 위해 계산하고, 해당 점수를 임계값과 비교하여 잠재적 명의도용자를 결정한다. 이 예에서, 도 8d를 참조하면, 알고리즘은 프로파일명에 사용된 모든 키릴 문자가 피해자를 속이기 위한 것이라고 가정한다. 프로파일명이 모든 키릴 문자로 구성된 경우, 트위터 크롤러 시스템은, 응답자 핸들러의 프로파일명을 인플루언서의 프로파일명으로 변환하기 위해 계산된 Levenshtein 거리 점수를 리턴하도록 구성된다. 프로파일명이 영문자와 키릴 문자로 구성된 경우, 트위터 크롤러 시스템은, 응답자 핸들러의 프로파일명을 인플루언서의 프로파일명으로 변환하기 위해 계산된 Levenshtein 거리 점수로부터 키릴 문자 수를 빼서 연산된 점수를 리턴하도록 구성된다. 도 8c의 예에서, Levenshtein 거리 점수는 6이고 키릴 문자가 6개이므로, 리턴된 테스트 점수는 0이다. 리턴된 점수가 낮을수록, 두 개의 프로파일/핸들이 더 유사하다. 리턴된 점수가 임계값 이하면, 감시 중인 계정은 잠재적 명의도용자로서 플래그 표시된다. 리턴된 점수가 임계값보다 크면, 감시 중인 계정은 합법적인 인플루언서 계정과 상당히 다를 수 있다. 이는, 리턴된 점수가 임계값보다 크면 감시 중인 계정이 잠재적 명의도용자가 아닐 가능성이 높다는 것을 의미한다.
다시 도 8a를 참조해 볼 때, 다음 조건들 중 하나 이상이 충족되는 경우, S810에서 검색된 각 트위트 응답의 콘텐츠가 분석되고 잠재적으로 악성으로 플래그 표시된다.
(i) 단계 S806에서 검색된 트위트 응답이 TRDB에 저장된 하나 이상의 키워드와 지갑 어드레스의 존재를 포함하는 것으로 결정된다.
(ii) 단계 S806에서 검색된 트위트 응답이 TRDB에 저장된 키워드와 URL의 존재를 포함하는 것으로 결정된다.
(iii) 검출된 URL이 TRDB에 저장된 하나 이상의 악성 html 패턴 및/또는 알 수 없는 지갑 어드레스를 포함하는 것으로 결정된 경우, 또는
(iv) 검출된 지갑 어드레스 또는 URL이 TRDB에 저장된 블랙리스트 기록과 일치하는 것으로 밝혀진 경우.
위 조건들의 조합을 사용하여 허위 긍정의 비율을 낮출 수 있다. 예를 들어, 트위트 응답이 TRDB에 저장된 하나 이상의 키워드와 하나 이상의 URL을 포함하는 경우에만, 그리고 트위트 응답의 검출된 URL이 TRDB에 저장된 하나 이상의 악성 html 패턴을 포함하는 것으로 결정되면, 트위트 응답은 잠재적 악성으로서 플래그 표시된다. 조건들의 조합을 사용하면 허위 긍정의 검출 비율을 낮출 수 있다. 상기 조건들은 본 명세서에서 의심스러운 트위트를 플래그 표시하기 위한 조건으로서 통칭될 수 있다.
단계 S810을 도 9를 참조하여 상세히 설명한다. 단계 S902에서는, 트위트 응답의 내용이 검색된다. 대안으로, 복수의 트위트 응답의 내용이 조사를 위해 검색 및 예약되며, 각 트위트 응답은 트위트 ID에 의해 식별될 수 있다. 단계 S904에서, 트위터 계정의 트위트 내용(또는 응답)은 TRDB에 저장된 (보내기, 에어드롭, 지갑 등의) 키워드에 대해 체크된다. 사용자 및/또는 센티넬은, TRDB의 키워드 관리 기능을 사용하여 트위트 내용을 통해 체크할 키워드를 추가, 제거, 또는 편집할 수 있다. (정확한 일치, 부분 일치, 와일드 카드를 사용한 키워드 검색 등의) 통상적인 키워드 검색 알고리즘을 또한 사용하여, 트위터 크롤러 시스템의 트위트 응답에서 검출되는 임의의 키워드(들)가 있는지 여부를 결정할 수 있다.
그 후, 단계 S906에서, 트위트 내용도 지갑 어드레스의 존재에 대하여 체크된다. 일례로, regex를 이용하여, 규정된 포맷의 지갑 어드레스를 검출할 수 있다. 규정된 포맷의 몇 가지 예는 다음과 같다.
비트코인
a) P2PKH ('1'로 시작하며, 26-35개 길이의 문자, 영숫자). 일례는
Figure 112020142427231-pct00003
이다.
b) P2SH ('3'으로 시작하며, 26-35개 길이의 문자, 영숫자)． 일례는
Figure 112020142427231-pct00004
이다.
c) Bech32 ('bc1'로 시작하며, 26-35개 길이의 문자, 영숫자). 일례는
Figure 112020142427231-pct00005
이다.
이더리움
a) 표준 ('0x'로 시작되며, 40개 영숫자가 후속됨)．일례는
Figure 112020142427231-pct00006
이다.
단계 S908에서는, URL 링크에 대해 트위트 내용도 체크된다. 각 트위트에서 검출된 모든 URL에 대해, 각각의 URL 링크가 확장되고, 예를 들어, 단계 S910에서 샌드박스를 통해 리다이렉션되어 해당 HTML 코드를 검색한다. 후속하여, 단계 S912에서, 리다이렉션된 URL 링크에 해당하는 HTML 코드를 검색한 후, 트위터 크롤러 시스템은, 검색된 HTML 코드가 TRDB에 정의된 임의의 악성 패턴을 포함하는지 여부를 체크하도록 구성된다. 악성 패턴의 일부 예로는, "어드레스 검증", "클립보드에 어드레스 복사", 및 "결제 대기 중"과 같은 텍스트 문자열의 검출이 있다. 트위터 크롤러 시스템은, 가능한 위협을 검출하면, S914 단계에서 지갑 어드레스(ETH 어드레스, 비트코인 어드레스, 또는 링크일 수 있음)에 대하여 HTML을 스캔하고 및/또는 단계 S916에서 사이트의 스크린샷을 찍하도록 구성된다. 이러한 스크린샷은 향후 악성 콘텐츠의 증거로 될 수 있다. 다른 일례로, 검출된 지갑 어드레스(들) 및/또는 URL 링크(들)는 TRDB에 저장된 블랙리스트와 비교된다. 또한, 인공 지능 또는 머신 러닝을 이용하여 악성 html 패턴을 식별할 수 있다. 트위터 크롤러 시스템은 센티넬 포털에 통합될 수 있다는 점을 이해해야 한다.
단계 S918에서, 트위터 크롤러 시스템은, 메모리에 저장된 프로그램(명령어)을 실행하여, 감시를 위해 TRDB에 저장되어 있는 인플루언서 트위터 계정에 대한 트위트 응답이 의심스러운 트위트를 플래그 표시하기 위한 조건들 중 임의의 한 조건을 충족하는지를 결정하도록 구성된다. 의심스러운 트위트를 플래그 표시하기 위한 조건은 다음과 같다.
(i) 트위트 응답이 TRDB에 저장된 키워드와 지갑 어드레스를 포함하고 있다고 결정되는 경우
(ii) 트위트 응답이 TRDB에 저장된 키워드와 URL을 포함하고 있다고 결정되는 경우
(iii) 트위트 응답의 URL이 TRDB에 저장된 (텍스트 문자열 포맷의) 악성 html 패턴을 포함하고 있다고 결정되는 경우, 및/또는
(iv) 트위트 응답의 지갑 어드레스 또는 URL이 TRDB에 저장된 블랙리스트 기록과 일치하는 것으로 결정되는 경우.
검색된 트위트 응답이 의심스러운 트위트를 플래그 표시하기 위한 조건들 중 임의의 하나를 충족하는 것으로 결정되면, 트위트 응답은 단계 S920에서 센티넬에 의한 추가 검증을 위해 플래그 표시된다. 일례로, 해당하는 의심스러운 트위트의 트위트 ID는 TRDB에 기록된다. 다른 일례로, 트위터 크롤러 API에 의해 의심스럽지 않은 것으로 결정된 트위트 응답의 트위트 ID가 기록될 수 있다.
다시 도 8a를 참조해 볼 때, 트위터 크롤러 시스템은 단계 S812에서 위협 결과를 생성하도록 구성된다. 생성된 위협 결과는 플래그 표시된 트위터 계정과 의심스러운 트위트를 포함한다. 생성된 위협 결과는, 단계 S814에서 센티넬(예를 들어, 도 1의 150, 도 2의 A-J)에 의한 유효성 검증을 위해 TRDB로 전송된다. 센티넬에 의한 유효성 검증 프로세스는 도 10a를 참조하여 자세히 설명되어 있다.
잠재적 명의도용자 또는 잠재적 악성 트위트가 트위터 크롤러 시스템에 의해 보고되거나 검출되면, 센티넬의 위협 결과(1002) 조사가 시작된다. 이것이 실제 위협으로 검증되면, 데이터는 블랙리스트에 있는 계정(1006)에 저장되거나 이에 따라 TRDB의 트위트(1016)에 보고된다. 허위 긍정(즉, 보안 위협이 아님)으로 검증되면, 데이터는 이에 따라 화이트리스트 계정(1008)에 저장되거나 TRDB의 트위트(1018)에서 클리어된다.
일례로, 도 10c를 참조하면, 플래그 표시된 트위터 계정이 블랙리스트에 오른 후 플래그 표시된 트위터 계정에 대해 추가 조사가 수행된다. 특히, 트위터 크롤러 시스템은 새롭게 블랙리스트에 오른 트위터 계정의 모든 트위트를 크롤링하도록 구성된다. 유리하게도, 트위터 크롤러 시스템은, TRDB에 저장된, 인플루언서가 트위트에 응답하지 않는 악성 트위트를 찾아낼 수 있다. 도 8a와 도 9를 참조하여 설명한 유사한 단계들(예를 들어, 트위트에서의 URL 또는 지갑 어드레스의 검출)을 구현하여 새롭게 블랙리스트에 오른 트위터 계정의 악성 트위트를 식별할 수 있다. 새롭게 블랙리스트에 오른 계정의 트위트가 의심스러울 가능성이 있다고 결정되면, 트위트는 센티넬의 추가 조사를 위해 플래그 표시된다. 대안으로, 의심스러운 트위트는 TRDB에서 악성 트위트로서 업데이트될 수 있다. 트위터 크롤러 시스템에 의해 처리된 인플루언서의 트위트에 응답하는 트위트는 효율성을 위해 건너뛸 수 있다는 점을 이해해야 한다.
새롭게 블랙리스트에 오른 트위터 계정의 검색된 트위트가 악성인지 여부를 결정하는 데 사용되는 검출 기준은, 블랙리스트에 오른 계정의 트위트가 악성일 가능성이 더 높기 때문에 다를 수 있다. 예를 들어, 연산된 시험 점수와 비교하기 위해 사용되는 임계값이 달라질 수 있다.
피싱 및 명의도용 검출 시스템(또는 트위터 크롤러 시스템)은, 도 10b의 10개의 표시자("1) # Legitimate imposters found to date"로 시작되는 것 등)과 같은 주요 성능 표시자를 포함하는 대시보드를 제공할 수 있다. 대시보드는 차트 등을 포함하는 표현가능한 포맷일 수 있다.
피싱 및 명의도용 검출 시스템에서 센티넬 프로토콜을 사용하는 것과 관련된 예는 도 4 내지 도 7, 도 8a 내지 도 8i, 도 9a 내지 도 9e, 및 도 10a 내지 도 10d에 도시되어 있다. 여기에 개시된 기술은 페이스북 등의 다른 소셜 네트워킹 플랫폼에 사용될 수 있음을 이해해야 한다. 또한, 악성 데이터가 온라인으로 검출될 때 사용자에게 전송되는 경고를 다양하게 수정할 수 있다. 일례로, 경고는 팝업 창으로서 표시될 수 있거나 웹 브라우저 페이지에서 안전 막대로서 표시될 수 있다. 여기서 사용되는 안전 막대는, 검출 결과에 따라 강조 표시되는 브라우저의 내비게이션 막대, 또는 경고 메시지를 나타내거나 검출 결과의 색상 표시자(예를 들어, 안전한 웹사이트에 대해서는 녹색, 악성 웹사이트에 대해서는 빨간색)를 표시하도록 브라우저의 내비게이션 막대의 근접하게(예를 들어, 아래, 왼쪽, 오른쪽 또는 위에) 배치된 막대를 지칭할 수 있다. 경고 표시의 다른 구성은 도 16a, 도 16b, 도 17a, 도 17b, 및 도 18에 예시될 수 있다.
이러한 경고 표시를 수정하는 데 사용되는 미리 정의된 설정의 몇 가지 예는 도 11 내지 도 15에 도시되어 있다. 예를 들어, 트위터 배지 또는 경고에 대한 암호화를 위한 안전 막대 설정, 블랙리스트 설정, 및 주석 설정을 수정할 수 있다. 일례로, 도 14를 참조하면, 안전 막대의 위치와 색상은 (표시되는 경우) 사용자 선호도에 맞게 맞춤화될 수 있다.
도 11은 브라우저에서 구현하기 위한 웹 플러그인의 일례이다. 자동보고 모드가 비활성화되어 있음을 알 수 있다. 사용자가 의심스러운 위협 활동을 수동으로 보고하기 위한 선택 버튼(1106)이 제공된다. 또한, 사용자가 자동 보호를 활성화하고/하거나 트위터 배지에 대한 안전 막대 설정, 블랙리스트 설정, 및 주석 설정을 수정하거나, 암호화 지갑 어드레스를 경고로서 강조 표시할 수 있는 설정 버튼(1102)이 있다. 도 12에 도시된 바와 같이, 트위터 배지(예를 들어, 도 17a의 1705)를 활성화하고 암호화 지갑 어드레스를 강조 표시할 수 있는 토글 버튼이 제공된다.
1. 안전 막대 설정(도 14 및 15 참조):
a. 특정된 시간에 안전 막대가 자동으로 사라지도록 하는 옵션(즉, 디폴트 5초 표시).
b. 안전 막대 레이아웃의 수정(상단, 하단, 상단 배너, 또는 하단 배너)
c. 안전 막대의 크기 변경
d. 안전 막대의 색상 변경
e. 안전 막대 기능을 비활성화하기 위한 온/오프 전환
f. 사라짐 시간은 화이트리스트 랩에서 정의될 수 있음.
2. 주석 - 트위터 배지
a. 트위터 사용자 옆에 트위터 배지를 추가한다. 트위터 크롤러 API를 사용할 때 트위터 프로파일명 옆에 추가된 트위터 배지는 트위터 서비스 공급자가 제공하는 보안 배지(예를 들어, 도 6의 605)와 다르다는 점을 이해해야 한다. 트위터 서비스 공급자가 제공하는 보안 배지는 사용자의 요청시 (검증 후) 발행된다. 그러나, 가짜(허위) 트위터 계정을 소유한 악성 행위자는, 트위터 서비스 제공자로부터의 보안 배지 발행을 요청할 가능성이 낮다. 이것은 일반 대중이 진본 트위터 계정으로 가짜 트위터 계정을 식별할 수 없음을 의미한다.
도 17a와 도 17b를 참조하면, 트위터 크롤러 API는, (TRDB에 저장된) 감시되고 있는 모든 인플루언서 계정 및 인플루언서 계정들 중 임의의 것에 응답하는 계정에 배지(1705)를 제공한다. 합법적인 인플루언서 계정의 프로파일명은 "Justin Sun"이고, 해당 핸들러는 "@justinsuntron"이다. 이에 비해, (합법적인 인플루언서 계정을 모방하는) 가짜 트위터 계정의 프로파일명은 "Justin Sun @justinsuntron"이며, 가짜 트위터 계정의 핸들러는 독자에게 표시되지 않는다. 이것은, 독자가 이 가짜 계정이 합법적인 인플루언서 계정의 실제 핸들러를 가지고 있다고 오해하게 한다.
배지(1705)의 색상 표시는 TRDB에서 트위터 계정의 현재 상태를 반영한다. 일례로, 배지는 화이트리스트의 경우에는 녹색이고 블랙리스트의 경우에는 빨간색이다. 다른 일례로, 위협 평판 데이터베이스로 체크되지 않은 트위터 계정은 노란색 배지로 표시될 수 있다(도면에 도시되지 않는다).
b. TRDB로의 데이터 동기화
c. 트위터 배지를 클릭하면 포털의 표시자/상세 화면(1707)으로 이동한다.
TRDB의 화이트리스트 및 블랙리스트 트위터 데이터를 활용하면, 배지를 프로파일명 근처에 표시하는 것 외에, 연관된 트위터 계정이 신뢰됨/신뢰되지 않음을 사용자에게 알리는 것을 표시할 수 있으며, 오버레이도 사용할 수 있다. 예를 들어, 도 18에 도시된 바와 같이, 신뢰되지 않는 계정에는, 신뢰되지 않는 계정 트위트에 오버레이된 빨간색 필터가 있다. 이러한 필터 오버레이의 일 구현예에서, 신뢰되지 않는 트위트에 대해 사용자에게 강조 표시하는 오버레이는 리트위트에도 적용될 수 있다. 이 필터는 빨간색(디폴트) 이외의 다른 색상으로 표시하도록 구성될 수 있다.
3. 화이트리스트:
a. 안전 막대(온/오프)
b. 표시 시간(초)
c. 팝업 레이아웃 유형(상단, 하단)
d. 서체 크기
4. 블랙리스트(도 13):
a. 오버레이(즉, 디폴트 설정) 대신, 리다이렉션도 가능하다.
b. 새로운 Punycode URL 차단 기능을 포함한다. 사용자가 어드레스 막대에 타이핑하여 Punycode URL로 이동하려는 경우, 센티넬 프로토콜은 이를 즉시 차단하거나 오버레이할 수 있다. 많은 피싱 웹사이트가 Punycode를 사용한다는 주목해야 한다.
선택적으로, 센티넬 프로토콜은 온-페이지 악성 암호화 지갑 어드레스를 검출하도록 구성된다. 선택적으로, 센티넬 프로토콜은, 사용자가 블랙리스트 사이트에 도달한 경우 페이지 리다이렉션을 선택할 수 있도록 구성된다.
5. 사례 등록 버튼(지금 보고)
a. 사례 등록 버튼을 전면에 배치
센티넬 프로토콜에 멀웨어 방지를 위한 파일해시 지원을 포함할 수도 있다. 예를 들어, 파일해시 지원은, 멀웨어 페이로드 검출을 위한 MD5 및 SHA256 파일해시 지원을 포함할 수 있다. 센티넬 프로토콜을 기반으로 한 블록체인 네트워크의 데이터는 이러한 파일해시 기술에 따라 해싱될 수 있다.
제안된 사이버보안 장치 및 방법의 예의 추가 특징은 다음과 같다.
암호화 분석 위험 평가( CARA )
악성 행위자는, 가명과 같은 고유한 속성 및 각 블록체인 시스템/네트워크의 여러 홉에 걸쳐 거래 추적시의 어려움 때문에, 자금 세탁 활동을 위해 암호화폐를 광범위하게 사용해왔다. 따라서, 암호화폐 거래는 악성 행위자가 운영할 수 있는 유리한 통로이며, 이는 블록체인 기술 사용에 대한 대중의 반대를 초래한다.
본 개시 내용에서 설명하는 제안된 사이버보안 장치 및 방법은, 이더리움 생태계와 같은 암호화폐 생태계 내에서 악성 행위자가 사용하는 악성 지갑을 식별하는 방법을 더 포함할 수 있다. 이 방법의 일례에서, 이러한 악성 지갑은 동일한 블록체인 네트워크의 노드들로부터만 식별된다. 본 개시 내용에서 암호화 분석 위험 평가(CARA) 알고리즘이라고도 하는 2-클래스 이상 검출 알고리즘을 이 방법에 사용하는 것을 제안한다.
CARA 알고리즘
CARA 알고리즘은, 알려지지 않은 지갑에서 유사한 패턴을 찾기 위해 알려진 악성 지갑 및 정상 지갑이 나타내는 거동을 학습하여, 이들 지갑을 악성 지갑, 매우 의심스러운 지갑, 의심스러운 지갑, 또는 정상 지갑으로 분류한다. CARA 알고리즘은, CARA 알고리즘의 인공 지능이 악성 지갑과 정상 지갑 모두의 거동을 학습하도록 구성되어 있기 때문에, 2-클래스 이상 검출 알고리즘으로 간주되며, 이는 대부분 정상 지갑으로부터만 학습하고 이어서 학습 후에 의심스러운 지갑이 무엇일지를 계산하는 다른 가능한 1-클래스 알고리즘에 비해 더 효율적이다.
악성 지갑과 정상 지갑의 거동 패턴에는 약간의 차이가 있다. 신용 사기, 피싱, 랜섬웨어 캠페인과 같은 활동에 관련된 악성 지갑은, 다수 홉에 걸쳐 다수의 중간 지갑을 통해 해당 토큰을 배포함으로써 관련 당국의 추적을 회피하려 한다. 블록체인에서, 홉은 두 개의 노드 간의 접속이며, 이는 두 개의 노드 간의 거래를 나타낸다. 관련된 거래는 토큰의 구매 또는 판매일 수 있다. 본 명세서에서, "토큰들" 또는 "토큰"은, 블록체인의 암호화폐의 네이티브 코인, 또는 블록체인에서 생성된 이차 토큰을 지칭한다. 이더리움의 경우, 네이티브 코인은 이더이며, 이차 토큰은 이더리움 블록체인에 구축된 거래를 위한 다른 수단일 수 있다. 이러한 이차 토큰은 값 0으로 시작하고, 그 후속 값은 시장에서의 수요와 공급에 의해 (예를 들어, 거래소에서 거래 후에) 결정된다.
악성 지갑에 의한 토큰 배포는, 수신된 토큰을 더 적은 양으로 지속적으로 분할하는 많은 인스턴스를 종종 포함하며, 이러한 양은 나중에 떨어져 있는 많은 홉에서 집계된다. 이 배포는, 악성 지갑으로부터 거래소로의 거래를 추적하기 어렵게 하기 위해 악성 행위자에 의해 수행된다. 이러한 방식으로, 악성 행위자는 수집된 이더 또는 토큰 등을 성공적으로 현금화할 수 있다. 악성 행위자는, 또한, 전술한 바와 동일한 방식으로 기능하는 서비스를 제공하는 암호화폐 텀블러 또는 믹서와 같은 서비스 제공자를 이용하여, 자금의 원래 출처로 돌아가는 흔적을 모호하게 할 수 있다.
반대로, 거래 지갑과 같은 정상 지갑이나 채굴 지갑은, 해당 추적을 커버하기 위해 이러한 난독화 기술(obfuscation techniques)을 거의 사용하지 않으며, 거래소 또는 기타 서비스(스마트 계약)와 직접적으로 또는 (악성 지갑의 거동에 비해) 적은 수의 홉을 통해 대부분 거래한다. 따라서, 악성 행위자가 사용하는 난독화 패턴을 학습함으로써, CARA 알고리즘은, 악성 행위자가 여러 홉 중계를 위해 사용하는 악성 지갑과 중간 악성 지갑을 식별할 수 있고, 이들 지갑을 블랙리스트에 올릴 수 있다. 예를 들어, 블랙리스트 올림은, 센티넬 프로토콜을 통해 또는 TRDB의 블랙리스트 기록의 자동 업데이트를 통해 악성 활동에 대한 보고서를 전송함으로써 수행될 수 있다.
도 19a에 의해 예시된 일례에서, CARA 알고리즘을 예시하는 흐름도(1900)가 있다. 제1 단계(1903)에서는, 특정 암호 화폐지갑을 검사하여 검사된 지갑에 대한 자금 세탁 방지(anti-money laundering, AML) 활동의 가능성을 결정하도록, 사용자, 머신, 또는 데이터베이스로부터의 입력이 수신된다. CARA 알고리즘은, 검사된 지갑이 악성 지갑일 가능성을 나타내는 위험 점수를 연산하기 위한 3개의 기능(1905, 1907 및 1909)을 갖는다. 이 예에서, 위험 점수가 높을수록 검사된 지갑이 악성일 확률이 높다. 이 예에서, 프로세서는 CARA 알고리즘의 3개의 기능을 수행하기 위해 메모리의 명령어를 실행하도록 구성될 수 있다. 3개의 기능은 다음과 같이 설명된다.
기능 1(1905): 바로 이웃 분류(Immediate Neighbour Classification)
기능 1(1905)은, 검사된 지갑의 바로 이웃 지갑(immediate neighbour wallets)을 분류하여 이들이 악의가 없는 지갑, 의심스러운 지갑, 또는 악성 지갑인지 여부를 나타낸다. 바로 이웃 지갑은, 검사된 지갑에 토큰을 전송하는 소스 바로 이웃 지갑(immediate source neighbour wallet), 또는 검사된 지갑으로부터 토큰을 수신하는 목적지 바로 이웃 지갑(immediate destination neighbour wallet)을 지칭한다. CARA 알고리즘은, 블록체인 거래의 정보, 예를 들어, 검사 대상의 지갑 어드레스, 거래 해시, 거래 식별자 등을 취득한 후, 검사된 지갑과의 적어도 하나의 거래에 직접 관련된 하나 이상의 바로 이웃 지갑을 맵핑한다.
도 19b는, 검사된 지갑(1960)의 거래 경로 및 바로 이웃 지갑(immediate neighbour wallets)(1962 및 1964)의 거래 경로를 정의하는 맵을 도시한다. 미리 정의된 기간 동안 맵이 생성된다. 이 기간 동안, 모든 두 개의 지갑 간에 발생하는 거래는, 맵에서 토큰들의 순 흐름 방향을 나타내는 하나의 화살표로서 표시된다. 미리 정의된 기간에 두 개의 특정 지갑 간에 여러 거래가 있는 경우에는, 두 개의 지갑 간의 최종 순 거래 금액이 계산되고 이에 따라 화살표 방향이 구성된다. 바로 이웃 지갑은, 검사된 지갑(1960)의 업스트림(upstream)측 거래에 관련된 소스 바로 이웃 지갑(1962) 및 검사된 지갑(1960)의 다운스트림(downstream)측 거래에 관련된 목적지 바로 이웃 지갑(1964)을 포함한다. 이러한 맵은, 검사된 지갑(1960)의 거래 경로에서 악성 활동의 경향을 식별하기 위해 기능 1(1905)에 의해 생성된다. 구체적으로, 도 19b는, 검사된 지갑(1960), 검사된 지갑(1960)의 바로 이웃 소스 지갑(1962)을 S1 내지 S3으로 도시하고, 검사된 지갑(1960)의 목적지 바로 이웃 지갑(1964)을 D1 내지 D3으로 도시한다. 도 19b에서, R로 표시된 지갑은, 거래소와의 거래에 앞서 토큰 분할 또는 집계와 관련된 D3의 다운스트림측 중계 또는 중계 중인 지갑을 지칭한다. E로 표시된 지갑은, 거래를 위해 통상적으로 다양한 소스 지갑으로부터 토큰을 풀링하는 거래소에 속한 거래소 지갑을 지칭한다. 본 개시 내용에서 "거래소"라는 용어는, 오프-체인 또는 온-체인으로 행해질 수 있는 토큰 거래를 용이하게 하기 위한 서비스 제공자를 지칭한다. 오프-체인으로 행해지는 경우, 거래소는 중앙 집중형 거래소로 간주된다. 온-체인으로 행해지는 경우, 거래소는 분산형 거래소(DEX)로 간주된다. M으로 표시된 지갑은, 이미 알려진 악성 지갑이며(즉, 그 정보를 이용할 수 있음), 예를 들어, 위협 평판 데이터베이스(TRDB)의 블랙리스트에 열거된다. TRDB는 블록체인에 구축된 분산형 데이터베이스일 수 있다(예를 들어, 도 1의 110).
CARA 알고리즘은, 바로 이웃 지갑(1962 및 1964)(즉, S1 내지 S3 및 D1 내지 D3)으로부터 파생되는 홉의 수를 파라미터로서 고려한다. 예를 들어, D3에서 시작하여, 거래소 지갑(E)에 대하여 4개의 홉 H1 내지 H4가 있다. CARA 알고리즘은, 또한, 모든 지갑에 대한 토큰 분할 또는 집계의 인자를 파라미터로서 고려한다. 예를 들어, 도 19b의 중계 지갑(1954)은 2개의 분할 인자를 갖는 것으로 간주되며, 이 수는 출력 거래 수(즉, 이 경우 2) 대 입력 거래 수(즉, 이 경우 1)의 비에 의해 계산된다. 도 19b의 중계 지갑(1956)은 2개의 집계 인자를 갖는 것으로 간주되며, 이 수는 입력 거래 수(즉, 이 경우 2) 대 출력 거래 수(즉, 이 경우 1)의 비에 의해 계산된다. 검사된 지갑(1960) 및/또는 도 19b의 다른 지갑의 정보는, 예를 들어, 블록체인 탐색기 애플리케이션을 사용하여 검색될 수 있다. 여기서 블록체인 탐색기 애플리케이션은, 사용자가 블록체인에서 지갑 또는 노드에 대한 거래 정보를 검색하고 지갑 또는 노드의 거래를 추적할 수 있도록 블록체인을 보고 질의하는 검색 엔진처럼 동작하는 애플리케이션을 지칭한다. 이더리움용 블록체인 탐색기의 일례는 bloxy.info이다. bloxy 애플리케이션 프로그래밍 인터페이스(API)를 이용하여, 필터링된 질의를 전송하여 이더리움 블록체인에서 하나 이상의 노드에 대한 정보를 검색할 수 있다.
도 19b의 맵은 본 예에서 목적지 바로 이웃 지갑(1964)인 D1 내지 D3으로부터 다운스트림측으로 최대 5개 홉에 대해 생성된다. 검사된 지갑(1960)의 업스트림측 거래는, 불필요한 추적을 피하기 위해 즉각 소스 지갑(1962; S1 내지 S3)으로부터 1홉 떨어진 것으로 제한된다. 주목할 점은, 일단 거래가 거래소(예를 들어, 거래소 지갑 E)에 도달하면, (이더 또는 이차 토큰을 포함하는) 토큰이 대부분 현금화되기 때문에 추가 거래를 추적할 필요가 없다. 거래에 대한 추가 추적이 거래소 지갑(E)으로부터 수행되면, 악성 공격자가 전혀 취하지 않은 추적을 조사할 위험이 있다. 예를 들어, 도 19b의 예에서, D3의 다운스트림측 거래 추적은, 거래소(1957)에 도달하기 때문에 4홉에서 중단된다. 또한, CARA 알고리즘을 생성할 때, 대부분의 악성 활동이 통상적으로 5홉 거리 내에서 수행되는 것으로 밝혀졌다. 이러한 발견에 대한 자세한 내용은 나중에 설명합니다. 도 19b의 예에서, 소스 바로 이웃 지갑(S1 및 S2)은 거래소 지갑으로부터 직접 거래를 통해 토큰을 수신하였다. 이러한 S1 및 S2의 거동은 CARA 알고리즘에 의해 정상 지갑(즉, 악성이 아닌 지갑)과 유사한 것으로 간주된다. 그러나, 이 지갑(S3)이 TRDB의 블랙리스트에 열거된 알려진 악성 지갑(M)과 직접 상호작용하므로, 소스 바로 이웃 지갑(S3)은 CARA 알고리즘에 의해 악성 지갑(S3)으로 간주된다.
도 19b에서 생성된 것과 같은 특정 맵에서 악성 활동의 불필요한 추적(및 연산/처리)을 방지하기 위해, 추적을 중단하기 위한 중단 메커니즘 기준의 목록은 다음과 같이 제안된다.
1. 알려진 거래소 및 DEX 지갑(E)과의 만남;
2. TRDB에서 블랙리스트에 오른 알려진 악성 지갑(M)과의 만남; 및
3. 거래소 또는 DEX의 거동을 모방할 수 있는 비정상적으로 많은 수의 거래가 있는 지갑과의 만남.
암호화폐 공간에서, 많은 거래소 또는 유사한 서비스는 사용자에게 지갑 어드레스를 공개하지 않는 경향이 있다. 따라서, 특정 지갑 어드레스가 거래소 또는 유사한 서비스에 속하는지를 알 수 없다. 그러나, 특정 지갑 어드레스는 알려진 거래소도 갖는 유사한 특성을 기반으로 식별될 수 있다. 이러한 특징은 바로 이웃 지갑과의 비정상적으로 많은 거래가 있다는 것이다. CARA 알고리즘의 생성시 수행한 연구에 따르면, 알려지지 않은 지갑을 매우 활동적인 거래소를 모방하는 것으로서 간주하도록 이러한 바로 이웃 지갑의 수가 10,000 이상이며, 알려지지 않은 지갑을 덜 활동적인 거래소를 모방하는 것으로서 간주하도록 바로 이웃하는 지갑의 수가 500 이상으로 식별되었다. 이들 수는, CARA 알고리즘의 다양한 기능을 확립하도록 머신 러닝에 사용되는 알려진 악성 및 정상 지갑 인스턴스들의 확장 경로에서 발견된 알려진 거래소 지갑의 바로 이웃 통계를 포함하는 트레이닝 데이터세트로부터 학습되었다.
도 19b의 예로 돌아가서, 소스 바로 이웃 지갑(1962)으로부터의 업스트림측 거래에 대해 수행된 분석과 유사하게, 목적지 바로 이웃 지갑(1964)에 대해 동일한 분석이 수행된다. D1 및 D2로부터의 다운스트림측 거래는 정상으로 간주되며, D1 및 D2는 거래소(즉, 거래소 지갑(E))와 직접 거래되기 때문에 정상 지갑(즉, 악의적이지 않은 지갑)으로 간주되어야 한다. 그러나, D3은, 토큰이 토큰의 일부 집계 및 분할이 있는 중간 지갑을 통한 중계에 의해 목적지 바로 이웃 지갑(D3)으로부터 교환소 지갑(E)으로 전송되었기 때문에, CARA 알고리즘에 의해 의심스러운 것으로서 간주된다. 여러 중계 지갑(R)을 통한 이러한 형태의 토큰 중계는, 악성 행위자가 사용하는 난독화 기술을 보여주기 때문에 의심스러운 것으로 간주된다. 결과적으로, 목적지 바로 이웃 지갑(D3)은 CARA 알고리즘에 의해 의심스러운 지갑으로서 플래그 표시된다.
토큰 중계 중에, 악성 행위자는 다양한 유형의 중계 지갑을 사용하여 토큰을 거래소 지갑으로 세탁할 수 있다. 중계 지갑의 한 유형은, 종종 바로 인접 지갑(1962 및 1964)(예를 들어, S1 내지 S3 및 D1 내지 D3) 근처에 종종 발견되며, 구체적으로, 바로 이웃 지갑(1962 및 1964)으로부터 약 1홉 내지 2홉 떨어져 있다. 이러한 유형의 중계 지갑에는, 종종 바로 이웃 지갑이 거의 없으며, 특히 주요 악성 지갑과 매우 근접하기 때문에 바로 이웃 지갑이 10개 이하이다. CARA 알고리즘에서, 이러한 중계 지갑은 저 거래 중계 지갑(RL)으로 분류된다. 다른 유형의 중계 지갑은, 바로 이웃 지갑(예를 들어, S1 내지 S3 및 D1 내지 D3)으로부터 더 멀리서 발견될 수 있으며, 구체적으로, 바로 이웃 지갑(1962, 1964)으로부터 약 3개 이상의 홉만큼 떨어져 발견될 수 있다. 이러한 중계 지갑은, 이전 홉에서 발견된 저 거래 중계 지갑(RL)에 의해 이전에 분할된 토큰을 집계하기 시작한다. 따라서, 이러한 중계 지갑은 구체적으로 10개 초과 500개 미만의 많은 지갑과 상호 작용하기 시작한다. 이러한 유형의 중계 지갑은 중간 거래 중계 지갑(RM)으로 분류된다. 거래량이 500개 이상인 중계 지갑의 경우, 이러한 중계 지갑은 CARA 알고리즘에 의해 거래소 지갑으로 간주된다.
연산 중에, CARA 알고리즘은, 도 19b에 표시된 것과 같은 입력된 맵에서 목적지 바로 이웃 지갑(1964)과 소스 바로 이웃 지갑(1962) 모두로부터의 각 경로를 조사한다. 특히, CARA 알고리즘은 의심스러운 경로를 찾으며, 예를 들어, D3의 다운스트림측 거래가 의심스럽다. 이러한 의심스러운 경로는 머신 러닝으로부터 학습한 특성을 기반으로 CARA 알고리즘에 의해 식별된다. 주 성분 분석을 적용함으로써, 악성 행위자가 사용하는 다른 난독화 기법과 유사한 특성이 머신 러닝 단계 동안 트레이닝 세트로부터 학습된다. 예를 들어, 특성은 다음과 같을 수 있다.
1. 토큰을 집계 또는 분할하지 않고 직접 중계하는, 검사된 지갑(1960)의 목적지 지갑(1964) 또는 소스 바로 이웃(1962)으로부터 적어도 5개 홉. 이 특성을 예시하기 위해, 예를 들어 도 20a의 지갑(D3)의 업스트림측 거래를 참조하며, 이는 CARA 알고리즘에 의해 이 특성 하에서 의심스러운 것으로 간주된다. D3의 업스트림측 거래는 직접 중계의 D3으로부터 5개 홉을 포함한다.
2. 저 거래 중계 지갑(low transaction relay wallet)(RL)에 의한 토큰 분할 또는 집계의 적어도 4개 인자를 이용한 중계의, 검사된 지갑(1960)의 목적지 지갑(1964) 또는 소스 바로 이웃(1962)으로부터 적어도 4개의 홉. 이 특성을 예시하기 위해, 예를 들어 도 20b의 지갑(D3)의 업스트림측 거래를 참조하며, 이는 CARA 알고리즘에 의해 이 특성 하에서 의심스러운 것으로 간주된다. D3의 업스트림측 거래는 D3으로부터의 중계의 적어도 4개 홉을 포함한다. 특히, D3의 업스트림측 거래 경로는 D3으로부터 거래소 지갑(E)까지 최대 5개 홉을 가지며, 이는 D3으로부터 적어도 4개 홉의 기준을 충족한다. 또한, 거래 경로에는, 4개의 분할 인자(즉, 4개의 출력 대 1개의 입력)가 있는 RL(2002) 및 4개의 집계 인자(즉, 4개의 입력 대 1개의 출력)가 있는 다른 RL(2004)이 관련된다.
3. 중간 거래 중계 지갑(RM)에 의한 토큰 분할 또는 집계의 적어도 8개 인자를 이용한 중계의, 검사된 지갑(1960)의 목적지 지갑(1964) 또는 소스 바로 이웃(1962)으로부터 적어도 4개 홉. 이 특성을 예시하기 위해, 예를 들어 도 20d의 지갑(D3)의 업스트림측 거래를 참조하며, 이는 CARA 알고리즘에 의해 이 특성 하에서 의심스러운 것으로 간주된다. D3의 업스트림측 거래는 D3으로부터 중계하는 적어도 4개 홉을 포함한다. 특히, D3의 업스트림측 거래는 D3으로부터 거래소 지갑(E)까지 최대 5개의 홉을 가지며, 이는 "D3으로부터의 중계의 적어도 4개 홉"의 기준을 충족한다. 또한, 이러한 5개 홉의 거래 경로에는, 9개의 집계 인자(즉, 입력 9개 대 출력 1개)가 포함된 RM 지갑(2014)이 관련되며, 이는 8개의 집계 인자의 임계값을 초과한다.
4. 최소 2개의 중계 지갑(RL 및/또는 RM)을 포함하는 토큰의 적어도 2개의 응집 또는 분할 인자를 이용한 중계의, 검사된 지갑(1960)의 목적지 지갑(1964) 또는 소스 바로 이웃(1962)으로부터의 적어도 3개 홉. 이 특성을 예시하기 위해, 예를 들어 도 20c의 지갑(D3)의 업스트림측 거래를 참조하며, 이는 CARA 알고리즘에 의해 이 특성 하에서 의심스러운 것으로 간주된다. D3의 업스트림측 거래는 D3으로부터의 중계의 적어도 3개 홉을 포함하며, 거래 경로에는, 적어도 2개의 토큰 집계 또는 분할 인자를 이용한 적어도 2개의 중계 지갑이 관련된다. 특히, 도 20c에서, D3으로부터 거래소 지갑(E)으로의 거래 경로에는 최소 5개의 홉이 있으며, 이는 "D3으로부터의 중계의 적어도 3개 홉"의 기준보다 많다. "토큰의 적어도 2개의 집계 또는 분할 인자를 이용한 적어도 2개의 중계 지갑"의 기준은 도 20c에서 충족되며, 그 이유는, 거래소 지갑(E)에 대한 거래 경로에, 각각 2개의 분할 인자를 갖는 3개의 RL이 포함되기 때문이다. 특히, 2개의 분할 인자가 있는 RL(2006)(예를 들어, 2개의 출력 대 1개의 입력), 2개의 분할 인자가 있는 RL(2008)(예를 들어, 2개의 출력 대 1개의 입력), 및 2개의 분할 인자가 있는 RL(2010)(예를 들어, 2개의 출력 대 1개의 입력)이 있다.
5. 적어도 2개의 중계 지갑이 포함된 거래소 지갑의 직전 또는 직후에 토큰의 집계 또는 분할 인자가 10개 이상인, 단일 인스턴스. 이 특성을 예시하려면, 예를 들어 도 20f의 지갑(D3)의 업스트림측 거래를 참조하며, 이 거래는 CARA 알고리즘에 의해 이 특성 하에서 의심스러운 것으로 간주된다. D3의 업스트림측 거래는 거래소 지갑(E)에 대한 3개 내지 4개 홉의 거래 경로를 갖는다. 거래소 지갑에 대한 거래 경로에는, 2개 이상의 중계 지갑이 포함되며, 2개의 중계 지갑 중 하나인 RM 지갑(2016)은, 거래소 지갑(E)과 거래하기 직전에 10개의 집계 인자(즉, 10개의 입력 대 1개의 출력)를 갖고 있다.
도 20e는 전술한 2와 3에 의해 정의된 특성이 충족되어 지갑(D3)을 의심스러운 것으로서 간주하는 시나리오를 예시한다. D3의 업스트림측 거래 경로에는 D3으로부터의 중계의 적어도 4개 홉(특히, 거래소 지갑(E)에 대한 최소 5개의 홉)이 포함된다. 거래 경로에는, 분할 인자가 4개 이상인 RL(2012)이 있으며, 실제로는, 분할 인자가 7개 있다(즉, 7개의 출력 대 1개의 입력). 따라서, 2에 의해 정의된 특성이 충족된다. 또한 거래 경로에는, 8개의 집계 인자(즉, 8개의 입력 대 1개의 출력)가 있는 RM 지갑(2018)이 있다. 따라서, 3에 의해 정의된 특성도 충족된다.
위의 1 내지 5에서 정의된 특성의 모든 값(예를 들어, 최소 4개 홉, 최소 8개의 집계 인자, 최소 2개의 중계 지갑 등)은 각 특성에 대한 임계값을 나타낸다. 본 예에서, 이들 값은, 악성 지갑과 일반 지갑을 찰 구분한 것으로 알려진 악성 및 일반 지갑 인스턴스의 확장된 경로로부터 머신 러닝을 기반으로 취득된다. 머신 러닝 단계 동안 트레이닝 세트로부터의 이러한 지갑 세트의 거래 정보를 이용하여, 각 특성에 대한 임계값을 유도하였다.
도 19b를 다시 참조해 보면, 바로 이웃 목적지 지갑(D3)은, 2개의 분할 인자가 있는 2개의 중계 지갑(R)이 있어서 위의 4에 의해 정의된 특성에 맞기 때문에, CARA 알고리즘에 의해 의심스러운 지갑으로 플래그 표시된다.
따라서, 기능 1(1905)은, 예를 들어, 바로 이웃 지갑이 예컨대 TRDB의 블랙리스트에서 발견되면 바로 이웃 지갑이 "악성"으로서 표시되고, 위의 1 내지 5에 의해 정의된 특성에 기초하여 그와 같이 결정되면 "의심스러움"으로 표시되고, 또는, "정상"(즉, 악성이 아님)"으로 표시되도록 처리된다. 이렇게 정상, 악성, 또는 의심스러움으로 표시된 지갑은 추가 처리를 위해 다음 기능 2(1907)로 전달된다. 다른 일례로, 악성이나 의심스러움으로 표시된 지갑만이 추가 처리를 위해 다음 기능 2(1907)로 전달된다.
기능 2(1907): 태스크 분류
기능 1(1905)에서 바로 이웃 소스/목적지 지갑을 표시한 후, (검사 지갑이 동작하고 있는) 특정 블록체인의 정보를 포함하는 블록체인 탐색기 또는 데이터베이스로부터의 정보, 검사된 지갑이 바로 이웃 지갑들 각각과 얼마나 빈번하게 상호 작용하는지, 및 거래 동안 관련된 토큰의 양을 취득하도록 질의가 수행된다. 이것은 검사된 지갑이 나타내는 악의의 심각성을 정량화하도록 수행된다. 악성 지갑은 악성 및/또는 의심스러운 바로 이웃 지갑과 빈번하게 상호 작용하지만, 정상 지갑은 바로 이웃 지갑과 거의 상호 작용하지 않는다. 따라서, 기능 2(1907)를 통해, (악성 지갑을 악성이라고 올바르게 추측하는) 참 긍정(true positives)이 증가될 수 있고, (정상 지갑을 악성이라고 추측하는) 허위 긍정(false positives)이 감소될 수 있다.
기능 2(1907)는, 블록체인 탐색기 또는 (검사된 지갑이 동작하고 있는) 특정 블록체인의 데이터를 포함하는 데이터베이스로부터의 정보에 대한 질의로 시작된다. 예를 들어, 이더리움, bloxy API가 질의에 사용될 수 있다. 질의되는 정보는, 검사된 지갑이 소스 바로 이웃 지갑(1962) 및 목적지 바로 이웃 지갑(1964)과 함께 직접 수행하는 모든 거래에 대한 것이다. 도 21은, 검사된 지갑(1960)이 바로 이웃 지갑(1962 및 1964)과 함께 수행하는 각 거래에 대해 취득되는 정보를 예시한다. 도 21은 도 19b의 예와 관련된 정보를 도시한다. 즉, 지금 설명된 검사된 지갑은, 검사된 지갑(1960), 소스 바로 이웃 지갑(1962)(즉, S1 내지 S3), 및 목적지 바로 이웃 지갑(즉, D1 내지 D3)을 지칭한다. 검사된 지갑(1960)이 이더리움 블록체인에서 동작한다고 가정하면, 기능 2(1907)의 동작에서 Bloxy API를 사용하여 취득되는 정보는 도 21의 왼쪽에 그림으로 표시된다. 구체적으로, 검사된 지갑(1960)과 이 지갑의 바로 이웃(S1 내지 S3 및 Dl 내지 D3) 간의 각 개별 거래가, 각 개별 거래의 발생 시간 순서대로 표시된다. 각 개별 거래의 발생 시간에 대한 정보를 취득한 후, 이 정보는 기능 2(1907)에 의해 태스크라고 하는 객체로 변환된다, 태스크는, 바로 이웃 소스 및 목적지 지갑들과 검사된 지갑의 거래 집계로서 정의될 수 있다. 도 21의 왼쪽에 있는 시간축 정보에 따르면, 개별 거래는 S1, S2, S3, D1의 순서로 발생하였다. 이것은, 검사된 지갑(1960)이 S1, S2, S3으로부터 토큰을 수신한 후 토큰이 D1로 이체되었다고 해석될 수 있다. 이는, 도 21의 오른쪽에 있는 태스크 1과 관련된 거래 흐름으로서 시각적으로 표현될 수 있다. 태스크 1과 그 거래 흐름이 생성된 후, 검사된 지갑(1960)은 일부 잔액 토큰을 가질 수 있다. 이어서, 검사된 지갑(1960)은, S2와의 다른 거래에서 토큰을 수신하고, 이러한 토큰은 나중에 D2 및 D3으로 전송된다. 이는 도 21의 태스크 1에 대한 거래 흐름 다이어그램 아래에 있는 태스크 2와 관련된 거래 흐름으로서 시각적으로 표현될 수 있다. 도 19b의 예에 대한 S1 내지 S3 및 D1 내지 D3의 분류를 참조하면, 태스크 1은 S3이 기능 1을 사용하여 악성 지갑으로 분류되었기 때문에 악성 태스크이고, 태스크 2는 D3이 기능 1을 사용하여 의심스러운 것으로 분류되었기 때문에 의심스러운 태스크이다.
일례로, 검사된 지갑(예를 들어, 도 19b의 1960)의 바로 이웃 지갑(예를 들어, 도 19b의 1962 및 1964)을 검사된 지갑과 바로 이웃 지갑 간의 (시간축에서 발생하는) 거래에 기초하여 하나의 태스크와 연관짓는 규칙은 다음과 같을 수 있다.
1) 검사된 지갑과 소스 및 목적지 바로 이웃 지갑의 거래를 포함하는 주어진 시간축에 대해, 검사된 지갑이 시간축에서 거래한 첫 번째 소스 바로 이웃 지갑을 찾는다.
도 21에 예시된 예를 사용하면, 첫 번째 소스 바로 이웃 지갑은 S1이다.
2) 첫 번째 소스 바로 이웃 지갑을 찾은 후, 시간축으로 이동하여 검사된 지갑이 거래한 첫 번째 목적지 바로 이웃 지갑을 찾는다.
도 21에 예시된 예를 사용하면, 첫 번째 목적지 바로 이웃 지갑은 D1이다.
3) 첫 번째 목적지 바로 이웃 지갑을 찾은 후, 검사된 지갑이 거래한 다음 소스 바로 이웃 지갑 및 다음 소스 바로 이웃 지갑 직전에 검사된 지갑과 거래한 마지막 목적지 바로 이웃 지갑을 찾는다.
도 21에 예시된 예를 사용하면, 첫 번째 목적지 바로 이웃 지갑(D1) 후의 다음 소스 바로 이웃 지갑은 S2이다. 다음 소스 바로 이웃 지갑(S2) 직전의 마지막 목적지 바로 이웃 지갑은, 하나의 목적지 바로 이웃 지갑만이 있기 때문에, D1로 유지된다.
첫 번째 목적지 바로 이웃 지갑 후에 다음 소스 바로 이웃 지갑이 없고 첫 번째 목적지 바로 이웃 지갑 후에 더 많은 목적지 바로 이웃 지갑이 발견되면, 첫 번째 소스 바로 이웃 지갑으로부터 시작되는 모든 노드가 하나의 태스크에 연관됨을 이해해야 한다.
예를 들어, 도 21의 예에서, 제2 태스크에 대한 첫 번째 소스 바로 이웃 지갑은 S2이고, 첫 번째 목적지 바로 이웃 지갑은 D2이다. 그러나, 첫 번째 목적지 바로 이웃 지갑(D2) 후에 발생하는 다음 소스 바로 이웃 지갑은 없다. 결과적으로, 첫 번째 소스 바로 이웃 지갑(S2)으로부터 시작되는 모든 노드(즉, S2, D2, D3)는 태스크 2에 연관된다.
4) 다음 소스 바로 이웃 지갑과 마지막 목적지 바로 이웃 지갑을 찾은 후, 첫 번째 소스 바로 이웃 지갑으로부터 시작하여 마지막 목적지 바로 이웃 지갑까지의 모든 노드(즉, 바로 이웃 지갑)는 하나의 태스크에 연관된다. 도 21에 예시된 예에서, S1로부터 시작하여 D1까지의 모든 노드는 태스크 1에 연관된다. 다음 소스 바로 이웃 지갑(즉, S2)은, 다음 태스크의 시작점(즉, 첫 번째 소스 바로 이웃 지갑)이 되며, 단계 2), 3), 및 4)가 반복된다.
전술한 태스크의 구축 근거는 다음과 같다.
악성 지갑은, 일반적으로 소스 지갑으로부터의 목적지 지갑으로의 모든 거래를 즉시 소비하는 거동을 나타내거나, 소스 지갑으로부터의 토큰을 하나 이상의 목적지 지갑을 통해 소비하기 전에 상당한 시간 동안 그 소스 지갑으로부터의 토큰을 보유한다. 기능 2(1907)를 통해 수행되는 이러한 태스크 분류를 통해, 다음과 같은 유사한 거동 특성을 포착할 수 있다.
1. 목적지 지갑에 대한 모든 소스 거래의 즉각적인 소비(토큰 잔액이 약 O 및 보유 시간이 1일 이하); 및
2. 상당한 보유 시간 후의 모든 소스 거래의 소비(토큰 잔액이 약 O 및 보유 시간이 10일 이상).
주 성분 분석은, 기능 1(1905)에 대한 5개 특성을 결정하는 데 사용되는 트레이닝 세트 등의 적절한 트레이닝 세트에 대한 머신 러닝을 통해 상술한 두 개의 특성에서 값(예를 들어, 토큰 잔액 약 0, 보유 시간 1일 이하, 10일 이상 등)을 학습하도록 적용될 수 있다.
따라서, 기능 2(1907)를 통해, 바로 이웃을 포함하는 태스크에 대하여 위의 2가지 특성을 체크하여, 기능 1(1905)을 통해 분류된 캐스트들이 악성 또는 의심스럽다는 의심을 더욱 증가시킬 수 있다. 특히, 위의 2가지 특성은, 다음 기능 3(1909)의 작업인 각 태스크에 가중치 점수를 제공하는 데 도움이 된다.
기능 3(1909): 위험 점수
기능 3(1909)을 통해, 이전 기능 2(1907)에 의해 출력된 태스크 리스트로부터 검사된 지갑에 대한 위험 점수를 계산한다. 이 예에서, 위험 점수가 높을수록 검사된 지갑이 악성일 가능성이 더 높다. 다른 예에서, 이것은 낮은 위험 점수가 악성일 가능성이 더 높다는 것을 나타내도록 구성될 수 있다는 점을 이해할 수 있다. 기능 3(1909)의 제1 단계에서, 각 태스크는 다음에 따르는 기준에 기초하여 정상, 의심스러움, 매우 의심스러움, 또는 악성으로 분류되며, 가중치가 각 태스크에 연관되어, 태스크의 악의의 심각성을 0 내지 1의 범위로 나타낸다.
1. 정상 태스크: 정상 태스크에 관련된 바로 이웃 지갑은, TRDB에 존재하는 난독화된 경로 또는 알려진 악성 지갑을 통해 토큰/이더를 수신 또는 전송하지 않았다. 이러한 정상 태스크에는 가중치 0이 부여된다.
2. 의심스러운 태스크: 하나 이상의 바로 이웃 지갑은, 난독화된 경로를 통해 토큰을 수신 및/또는 전송하지만, 인입되는 모든 거래를 즉시 소비하지 않았으며 또는 10일보다 길게 보유하지 않았다. 이러한 활동은, 의심스러운 태스크를 나타내며, 가중치 0.5가 부여된다.
3. 매우 의심스러운 태스크: 하나 이상의 바로 이웃 지갑은, 난독화된 경로를 통해 토큰을 수신 및/또는 전송하고, 인입되는 모든 거래를 즉시 소비하거나 10일보다 길게 보유한 후 인입되는 모든 거래를 소비하여, 의심을 증가시킨다. 이러한 활동은, 매우 의심스러운 태스크를 나타내며, 가중치 0.75가 부여된다.
4. 악성 태스크: 하나 이상의 바로 이웃 지갑은, TRDB에서 블랙리스트에 올라있는 알려진 악성 지갑으로 토큰을 전송하고/하거나 수신한다. 이러한 활동은, 매우 의심스러운 태스크를 나타내며, 가중치 1이 부여된다.
위험 점수 연산에 관한 정보
이 예에서, 검사 중인 지갑의 위험 점수는, 3개의 메트릭, 즉, 불량 토큰의 양, 불량 태스크의 수, 및 불량 일의 수를 사용하여 연산된다. 불량 일은, 검사 중인 지갑이 하나 이상의 의심스럽거나 매우 의심스럽거나 악성의 태스크에 관여된 날로서 정의된다. 따라서, 하루에 일반 태스크만을 포함한 경우에, 이것은 양호한 날로 간주된다. 위의 3가지 메트릭을 선택한 이유는, 존재하는 대부분의 수명에 걸쳐(불량 일의 수가 수명과 거의 같음) 악의적으로 거동하고 많은 불량 태스크가 관여되는, 불량 태스크와 거의 모두(불량 태스크의 수가 총 태스크의 수와 거의 같음) 거래하는 지갑만이 100 중 60을 초과하는 높은 위험 점수를 갖기 때문이다. 존재하는 대부분의 수명 동안 악성 태스크에 관여하는 악성 행위자에 속하는 악성 지갑은 높은 위험 점수를 갖는 것을 정당화한다. 그러나, 일반 사용자는, 악성 지갑에 토큰을 전송하도록 신용 사기를 당함으로써 악성 거래에 실수로 관여하게 될 수 있다. 그렇지 않으면, 일반 거래에만 관여하는 일반 사용자는 토큰을 거래소에 직접 전송할 수 있다. 위에서 언급한 3가지 메트릭은, 하나의 불량 일에만 발생하였으며 모든 태스크에 걸쳐 거래되는 총 토큰에 비해 소량으로 이체되는 토큰을 포함한 하나의 불량 태스크에만 관여된 일반 사용자 지갑 등의 사례에 대하여 낮은 위험 점수를 연산하는 데 도움이 된다.
또한, 위험 점수를 연산하기 위해, 3가지 메트릭(즉, 불량 토큰의 양, 불량 태스크의 수, 불량 일의 수) 각각의 절대 불량값과 해당 퍼센트를 고려한다. 예를 들어, 불량 토큰의 %는, 모든 불량 태스크에 대해 거래된 총 불량 토큰을 모든 태스크에 대해 거래된 총 양호 및 불량 토큰과 비교함으로써 연산된다. 이는, 검사된 지갑이 높은 위험 점수를 가지려면, 각 메트릭의 절대 불량 값과 불량 값의 % 모두가 높아야 한다는 것을 보장한다. 이는, 일부 경우에, 검사 중인 지갑이 많은 의심스러운 태스크에 관여된 것으로 보일 수 있어서, 해당 날의 대부분을 불량 일로 만들기 때문이다. 그러나, 검사 중인 지갑에 의해 실제로 거래되는 불량 토큰의 양은, 적으며, 예를 들어, 불량 토큰의 %가 100일 수 있더라도, 1개 또는 2개의 토큰이다. 이러한 지갑은, 의심스럽지만, 예를 들어, 1개 또는 2개의 토큰보다 상당히 많은 100개의 불량 토큰을 거래한 유사 지갑보다 낮은 위험 점수를 가져야 하며, 이에 따라 더욱 의심스러운 것으로 간주된다. 위험 점수 연산 기술은, 3가지 메트릭 각각의 절대 불량 값과 불량 %를 모두 고려함으로써, 각 사례의 위험 점수를 조정한다.
예를 이용한 위험 점수화 기술의 설명
도 22는 위험 점수 연산을 설명하는 일례를 도시한다. 도 22는 이전 블록인 기능 2(1907)에 의해 출력된 두 개의 태스크인 태스크 1과 2를 도시한다. 태스크 1과 2는 도 21의 태스크 1과 2와 동일하다. 각 태스크 1과 2는 도 22에서 각 바로 이웃 지갑에 대해 거래된 토큰의 양을 도시한다. 도 22의 예에서는, 2개의 태스크가 같은 날에 발생하치 않았고 상이한 2일에 발생했다고 가정한다.
태스크 1은, 악성 태스크로 분류되며, 총 80개의 토큰 거래를 포함하며, 이들 중 70개의 토큰이 악성 소스인 S3으로부터 온 것이다. 위험 점수는, 먼저 [불량 토큰의 수, 불량 태스크의 수, 및 불량 일의 수]의 포맷으로 된 3가지 메트릭을 나타내는 행렬을 할당된 가중치로 승산하여 취득함으로써, 연산된다. 태스크 1에 대한 불량 값 메트릭은, 악성 소스로부터 70개의 불량 토큰이 나왔으므로 [70,1,1]*1로 계산되어, 태스크와 해당 날을 모두 악성 또는 불량으로 만들며, 이에 따라 불량 태스크의 수는 1이고, 불량 일의 수는 1이다. 1이 악성 태스크 1에 할당된 가중치이기 때문에, 행렬 (70,1,1)에 1을 곱한다. 언급해야 할 중요한 점은, 태스크 l과 2에 대해 불량 토큰의 절대값과 총 토큰의 절대값이 고려되고 계산된다는 것이다. 도 22에 도시된 바와 같이, 태스크 1은, 3개의 소스 바로 이웃(S1 내지 S3)으로부터 80개의 토큰을 수신한 다음 80개의 토큰을 모두 D1로 전송한다. 이 경우, 태스크 1에 의해 거래된 총 토큰은, 소스 바로 이웃 지갑으로부터 수신된 동일한 80개의 토큰이 목적지 바로 이웃 지갑(D1)에 의해 모두 소비된다고 가정하기 때문에, 160개 토큰(소스로부터의 80개 토큰 + 목적지로의 80개 토큰)이 아니라 80개 토큰이다. 이러한 방식으로, 임의의 태스크에 의해 거래되는 총 토큰은, 항상 목적지 바로 이웃 지갑으로 전송되는 토큰의 총량, 즉, 임의의 태스크에 대하여 발신되는 총 토큰이다. 따라서, 태스크 1에 의해 거래된 총 토큰의 절대값은 80개 토큰이다. 악성 소스(S3)로부터 70개의 불량 토큰이 수신되었고 목적지(D3)로 전송된 총 80개 토큰 중 이들 70개 토큰이 불량으로 간주되므로, 불량 태스크의 수는 1이다. 태스크 1이 1일에 발생했으므로, 불량 일의 수는 1이다. 따라서, 행렬 [80,1,1]은 태스크 1에 대한 총 값 메트릭으로서 계산된다.
태스크 2는 의심스러운 태스크로만 간주되며, 검사된 지갑은 총 20개의 토큰 중 목적지 바로 이웃 지갑(D3)에 18개의 불량 토큰을 거래한다. 태스크 2는, TRDB의 알려진 악성 지갑 리스트로부터 확실히 악성인 것으로 확인되지는 않았지만 의심스럽기 때문에, 가중치 0.5와 연관되어 있다. 태스크 2는 의심스러운 태스크이므로, 불량 태스크의 수는 1이다. 태스크 2는 1일에만 발생하므로, 불량 일의 수는 1이다. 따라서, 태스크 2의 불량 값 메트릭은 [18,1,1]*0.5와 같다. 태스크 2의 총 발신 토큰이 20이므로, 태스크 2의 총 값 메트릭은 [20,1,1]이다.
다음으로, 태스크 1과 태스크 2의 총 불량 값 메트릭과 총 값 메트릭이 합산된다. 합산 후에, 총 값 메트릭 [100,2,2]에 대해 불량 값 메트릭 [79,1.5,1.5]를 취득하게 된다. 이는, 총 100개의 토큰 중 79개의 토큰만이 불량으로 간주되고(즉, 79% 불량 토큰), 1.5 태스크는 총 2개 태스크로부터 불량으로 간주되고(즉, 75% 불량 태스크), 2일 중 1.5일은 불량 태스크를 포함하였음(즉, 75% 불량 일)을 의미한다. 이에 따라, 다음과 같이 3개 메트릭의 절대 불량 값과 불량 퍼센트 값이 계산된다. 이러한 3개 메트릭의 절대 불량 값 및 불량 퍼센트 값은, 태스크 1과 2에 관한 검사된 지갑의 위험 점수를 연산하는 데 이용된다. 위험 점수는 아래 제시된 수학식을 사용하여 계산된다.
절대 불량값 메트릭 : [79. 1.5, 1.5]
절대 불량% 메트릭 : [79%, 75%, 75%]
태스크 1과 태스크 2가 같은 날에 발생하는 시나리오에서, CARA 알고리즘은, 동일한 날이 이제 1개의 태스크(즉, 태스크 1)가 악성인 2개의 불량 태스크를 포함하기 때문에, 불량 일 절대값을 1로 계산하고 불량 일 %를 100%로 계산한다. 계산시, 악성 태스크에 우선순위가 부여된다.
특정 태스크에 대해 절대 불량값 메트릭 및 절대 불량 % 메트릭을 계산할 수 있는 방법에는 예외가 있다. 이러한 상이한 태스크 처리 사례는 다음과 같다.
도 23a와 도 23b를 참조하면, 도 22에 도시된 태스크 1과 2와는 상이한 계산의 대상이 되는 2개의 태스크인 태스크 3과 태스크 4가 도시되어 있다. 태스크 3과 4는 이전에 기능 1(1905)에 의해 악성 태스크로 분류되었다. 이러한 태스크 3과 4에서 소스 바로 이웃 지갑(S3)은 악성 지갑으로 분류되고, 이러한 태스크 3과 4에서 목적지 바로 이웃 지갑(D3)은 의심스러운 지갑으로 분류된다. 태스크 3과 4는 각각 1일에 수행되고, 태스크 3은 태스크 4보다 전에 수행되었다. 태스크 3과 4는, 검사 중인 공통 지갑에 관한 태스크이며, 다음과 같은 기능을 갖는다.
1. 소스 바로 이웃 지갑으로부터 수신된 총 토큰은 목적지 바로 이웃 지갑으로 전송된 총 토큰과 다르다. 태스크 3에서, 도 23a를 참조하면, 검사된 지갑의 3개의 소스 지갑 S1 내지 S3으로부터 총 80개의 토큰이 수신되는 한편, 수신된 총 80개의 토큰 중 50개만이 검사된 지갑의 목적지 바로 이웃 지갑 D1으로 전송된다. 태스크에서 거래된 총 토큰은, 검사된 지갑이 태스크 3의 D1인 목적지 바로 이웃 지갑으로 전송한 총 토큰과 동일하다. 따라서, 태스크 3은 D1과 50개의 토큰을 거래하고, 검사된 지갑은 이 시점에서 30개의 토큰 잔액을 가지고 있다. 태스크 4에서, 도 23b를 참조하면, 검사된 지갑은 3개의 소스 바로 이웃 지갑 S1 내지 S3으로부터 20개의 토큰을 수신하는 한편, 검사된 지갑은 태스크 4에서 50개의 토큰을 2개의 목적지 바로 이웃 지갑 D1 및 D2로 전송한다. 이는 검사된 지갑이 태스크 3 이후에 30개의 토큰 잔액을 가지고 있었고 이어서 태스크 4에서 소비되었기 때문이다. 따라서, 태스크 4는 20개의 토큰만 수신하였지만, 태스크 4는 총 50개의 토큰을 거래한 것이다. 따라서, 태스크 3과 4에 대해 계산된 총 절대값 메트릭(양호 거래와 불량 거래를 모두 고려함)은 각각 [50,1,1] 및 [50,1,1]이다.
2. 태스크 3에서, 소스 바로 이웃 지갑 S3으로부터 수신된 총 불량 토큰은 목적지 바로 이웃 지갑 D1로 전송된 총 토큰보다 많다. 이 경우, S3은 악성 지갑이므로, 태스크 3에 할당된 가중치는 1이고, CARA 알고리즘은 계산에서 S3으로부터 나오는 악성 토큰에 우선순위를 부여한다. S3으로부터 나오는 악성 토큰에 우선순위를 부여한다는 것은, 목적지 바로 이웃 지갑 D1로 전송된 50개의 토큰이 S1과 S2가 아닌 S3으로부터 모두 온다고 가정한다는 것을 의미한다. 이는, 일반적으로 악성 행위자가 거래소를 통해 현금화하기 위해 가능한 한 빨리 불량 토큰을 중계하려 하기 때문이다. 따라서, 태스크 3에 대한 절대 불량 값 메트릭은 [50,1,1]*1이고, 절대 총 값 메트릭(양호 고래 및 불량 거래 모두를 고려함)은 전술한 바와 같이 [50,1,1]이다. 이에 따라, 태스크 3 이후에는, 30개 토큰 중 20개가 불량 토큰이다.
3. 태스크 4는 악성 지갑 S3 및 의심스러운 지갑 D3과의 상호 작용을 포함한다. 태스크 4에서, 검사된 지갑은 악성 지갑 S3으로부터 10개의 불량 토큰을 수신하였다. 따라서, 태스크 3의 잔액에 있는 20개의 불량 토큰을 포함하면, 불량 토큰의 수는 30이 된다. 이 경우, CARA 알고리즘은, D3가 의심스럽고 따라서 우선적으로 고려되어 30개의 토큰 중 10개의 토큰만이 불량 토큰으로 간주되기 때문에, 검사된 지갑이 20개의 불량 토큰을 D3으로 전송하였다고 가정한다. 또한, CARA 알고리즘은 불량 토큰의 절대값을 2개의 값 중 큰 값으로 간주한다. 2개의 값 중 큰 값은 D3으로 전송된 20개의 불량 토큰이다. 검사된 지갑이 악성 소스 바로 이웃 S3과 상호 작용하므로, 태스크 4는 악성 태스크로 표시되며, 따라서 태스크 4에 할당된 가중치는 1이다. 따라서, 태스크 4에 대한 절대 불량값 메트릭은 [20,1,1]*1이고, 태스크 4에 대한 총 값 메트릭은 [50,1,1]이다.
태스크에 고려되는 토큰의 불량 값 계산, 작업 라벨 결정, 일 라벨(day label) 결정에 관한 규칙은 다음과 같이 요약된다. 첫째, 태스크에 대하여, 소스 바로 이웃 지갑으로부터 수신된 토큰의 총량을 고려하고 이를 총 입력 토큰량이라고 한다는 점에 주목해야 한다. 둘째, 목적지 바로 이웃 지갑으로 전송되는 토큰의 총량을 고려하고 이를 총 출력 토큰량이라고 한다. 따라서, 태스크에 의해 거래되는 토큰의 총 절대값은 항상 총 출력 토큰량이다.
태스크에 대하여 고려되는 토큰의 불량값을 결정하기 위한 if-else 조건은 다음과 같다.
if (총 입력 불량값 토큰 > 총 출력 불량값 토큰) ..... 조건 (1)
소스 바로 이웃 지갑으로부터의 불량값 토큰 > 목적지 바로 이웃 지갑으로 향하는 불량값 토큰일 때 조건 (1)을 관찰한다.
if (총 입력 불량값 토큰 <= 거래된 토큰의 총 절대값) ..... 조건 (2)
조건 (2)는, 소스 바로 이웃 지갑으로부터의 불량값 <= 토큰 거래된 토큰의 총값인지를 체크하는 것이다.
조건 (1)과 조건 (2)가 충족되면, 태스크에 대해 고려된 토큰의 불량값 = 총 입력 불량값 토큰이다.
그러나, 소스 바로 이웃 지갑으로부터의 총 불량 값 토큰 > 거래된 토큰의 총 값이면, 조건 (3)이 적용되고, 불량값 토큰은 (도 23c의 태스크 5의 사례와 같이) 거래된 토큰의 총 값으로 제한된다. 이 경우, 태스크를 위해 고려된 토큰의 불량값 = 거래된 토큰의 총 절대값이다.
목적지 바로 이웃 지갑의 불량값 토큰 > 소스 바로 이웃 지갑의 불량값 토큰인 경우, 조건 (4)가 적용되고, 태스크에 대해 고려된 토큰의 불량값 = 총 출력 불량값 토큰이다. 위험 인자를 계산하기 위해, 다음 판독값을 취득하거나/연산한다.
* 총 입력 토큰 금액 (TotalIN), 태스크에 의해 거래된 토큰의 총 절대값 Totaltransacted(즉, 총 출력 토큰 총액 TotalOUT), 토큰의 총 입력 불량값(TotalBAD IN), 토큰의 총 출력 불량값(TotalBAD_OUT)을 취득한다.
* 조건 (1) 내지 (4) 중 임의의 조건이 충족되는지를 체크한다.
* 위 조건 (1) 내지 (4)의 결정에 기초하여 토큰의 불량값을 결정한다.
태스크에 대한 불량값 메트릭 값을 연산하기 위해, 악성 바로 이웃 지갑에 우선순위가 부여되고, 그 다음에는 매우 의심스러운 지갑, 의심스러운 지갑, 마지막으로 정상 바로 이웃 지갑 순으로 우선순위가 부여된다. 따라서, 도 23b의 태스크 4의 경우, 태스크 4는 악성 소스 바로 이웃 지갑 S3 및 의심스러운 목적지 바로 이웃 지갑 D3과 거래한다. 악성 소스 바로 이웃 지갑 S3에 우선순위를 부여하는 것을 고려하고, 태스크 4를 악성으로 분류하고, 가중치 1로 할당한다.
태스크에 대한 태스크 라벨을 결정하기 위한 if-else 조건은 다음과 같다.
조건 (1a): 태스크가 하나 이상의 악성 바로 이웃 지갑을 포함하면,
조건 (1a)가 충족되면, 태스크 라벨 = '악성'
조건 (2a): 아니면, 태스크가 하나 이상의 매우 의심스러운 바로 이웃 지갑을 포함하면,
조건 (2a)기 충족되면, 태스크 라벨 = '매우 의심스러움'
조건 (3a): 아니면, 태스크가 하나 이상의 의심스러운 바로 이웃 지갑을 포함하면,
조건 (3a)가 충족되면, 태스크 라벨 = '의심스러움'
위의 조건 (1a) 내지 (3a) 중 어느 것도 충족되지 않으면, 태스크 라벨 = '정상'이다.
태스크에 대한 일 라벨을 결정하기 위한 if-else 조건은 다음과 같다.
조건 (1b): 하루에 1개 이상의 악성 태스크가 있는 경우, 일 라벨 = '악성'
조건 (2b): 아니면, 하루에 1개 이상의 의심스러운 태스크가 있는 경우, 일 라벨 = '매우 의심스러움'
조건 (3b): 아니면, 하루에 1개 이상의 의심스러운 작업이 경우, 일 라벨 = = '의심스러움'.
조건 (1b) 내지 (3b) 중 어느 것도 충족되지 않으면, 일 라벨= '정상'이다.
따라서, CARA 알고리즘에 의해 매일 거래도 고려할 수 있다.
도 23c를 참조하면, 태스크 5는 검사된 지갑의 소스 바로 이웃 지갑 S1 내지 S3 및 검사된 지갑의 목적지 바로 이웃 D1과 D3을 포함하는 거래를 도시한다. 태스크 5의 경우, S3과 D3은 모두 기능 1(1905)에서 의심스러운 것으로 인식되거나 분류되었다. 총 입력 토큰 금액(TotalIN)은 90이며, 태스크 Totaltransacted에 의해 거래된 토큰의 총 절대값(즉, 총 출력 토큰 총액 TotalOUT)은 30이고, 총 입력 불량값 토큰(TotalBAD IN)은 40이고, 총 출력 불량값 토큰(TotalBAD_OUT)은 20이다.
결과적으로, 다음에 따르는 조건의 상태는 아래와 같다.
조건 1: 충족됨 (S3으로부터의 40 > D3으로의 20)
조건 2: 충족되지 않음 (S3으로부터의 40 > 30, 여기서 태스크 5에서 거래된 토큰의 총 절대값은, 목적지 바로 이웃 지갑 D3으로 전송된 20개의 토큰과 목적지 바로 이웃 지갑 D1로 전송된 10개의 토큰을 고려하여, 30개 토큰이다)
조건 3: 충족됨 (40 > 30)
조건 4: 충족되지 않음 (20 < 40)
악성/의심스러운 지갑에 우선순위를 부여하면, 의심스러운 목적지 바로 이웃 지갑 D3에 의해 수신된 모든 20개의 불량 토큰은 의심스러운 소스 바로 이웃 지갑 S3으로부터 수신된 40개의 불량 토큰에서 나온 것이라고 가정한다.
조건 3, 즉, 총 입력 불량값 토큰 > 거래된 토큰의 총 절대값이 충족되므로, 태스크 5에서 고려되는 절대 불량값 토큰은 = 거래된 토큰의 총 절대값, 즉, 30개 토큰이다. 따라서, 태스크 5의 불량 토큰에 대한 % = 태스크 5에 대해 고려된 절대 불량값/태스크 5에서 거래된 토큰의 총 절대값 = 30/30 = 100%이다.
위험 점수를 계산하는 수학식
위험 점수 = 평균 (정규화된 악성 토큰 + 정규화된 악성 태스크 + 정규화된 악성 일) - (1)
정규화된 악성값 = (정규화된 절대 불량값 + 정규화되지 않은 불량값%) / 2 - (2)
정규화된 절대 불량값 = [(메트릭의 절대 불량값) * (메트릭의 불량값 %) / (메트릭의 최대 절대 불량값 * 노멀라이저 - (3)
수학식 (1)은, 수학식 (2)와 (3)을 사용하여 이러한 각 메트릭을 정규화한 후 3개 메트릭(토큰 양, 태스크 수, 일 수)으로부터 위험 점수를 계산하는 방법을 나타낸다.
수학식 (2)에서는, 각 메트릭의 절대 불량값만 정규화되는 한편, 메트릭에 대한 불량값 %가 직접 사용될 수 있는 0 내지 100의 양호한 범위를 갖기 때문에, 불량값 %는 정규화되지 않는다. 그러나, 각 메트릭의 절대 불량 값에는 고정 범위가 없으므로, 절대 불량값을 위험 점수 계산에 그대로 사용하기가 어렵다.
따라서, 수학식 (3)을 사용하여, 절대 불량값을 또한 범위에 맞도록 정규화한다. 절대 불량값을 정규화하기 위해, 메트릭의 절대 불량값과 메트릭의 % 불량값을 포함시켜, 절대 불량값과 % 모두가 높을 때에만 정규화된 절대값이 위험 점수를 증가시키며, 이에 따라 검사 중인 지갑에 의한 악성 활동의 관련 확신을 증가시킨다. 각 메트릭에 대하여, 메트릭이 특정 절대 불량값에 도달하면 이미 악성 거동의 표시자이기 때문에, 수학식 (3) 변수 "메트릭의 최대 절대 불량값"에 도시된 바와 같이 최대 캡이 제공된다. 주 성분 분석을 적용하면, 토큰, 태스크, 및 일에 대한 최대 절대 불량값은 머신 러닝에 의해 100, 7, 3으로 학습된다. 이들 임계값은, 적절한 트레이닝 세트 또는 기능 1(1905)의 5개 특성을 결정하는 데 사용되는 트레이닝 세트 등의 적절한 트레이닝 세트 또는 데이터에 기초하는 머신 러닝으로부터 결정된다.
또한, 수학식 (3)에서, 각 메트릭에 대한 불량값의 %를 기반으로 절대 불량값을 추가로 정규화하는 "노멀라이저"라는 다른 변수가 있다. 노멀라이저 변수의 근거는, 메트릭에 대한 불량값의 %가 높으면(예를 들어, 거래된 토큰의 60%가 불량) 검사 중인 지갑이 특히 악성 연산을 충족시킬 가능성이 더 크다는 것이다. 불량 메트릭의 %가 낮으면, 검사된 지갑이 정상이며 신용 사기의 일부로서 악성 지갑과 모르고 거래했을 가능성이 높다. 불량 메트릭의 다른 퍼센트에 대한 노멀라이저 값은 다음과 같다.
정규화된 값 불량 메트릭의 %
1 100%
2 75 내지 100% 미만의 값
3 50 내지 75% 미만의 값
4 25 내지 50% 미만의 값
5 0 내지 25% 미만의 값
표 1; 불량값 메트릭의 상이한 퍼센트에 대한 노멀라이저 값 분포
위험 점수 계산을 예시하기 위한 이전 예의 계속
도 22로 돌아가면, 절대 불량값 메트릭과 불량값 메트릭의 %가 아래와 같이 일찍 연산된다.
절대 불량값 메트릭: [79, 1.5, 1.5]
절대 불량 % 메트릭: [79%, 75%, 75%]
머신 러닝(주 성분 분석)에서 파생된, 최대 절대 불량값 메트릭: [100, 7, 3]
수학식 (3)을 사용하여, 토큰에 대한 정규화된 절대 불량값 = (79 * 79) / (100 * 2) = 31.2
수학식 (2)를 사용하여, 정규화된 악성 토큰 = (31.2 + 79) / 2 = 55.1
수학식 (3)을 사용하여, 태스크에 대한 정규화된 절대 불량값 = (1.5 * 75) / (7 * 2) = 8.0
수학식 (2)를 사용하여, 정규화된 악성 태스크 = (8.0 + 75) / 2 = 41.5
수학식 (3)을 사용하여, 일에 대한 정규화된 절대 불량값 = (1.5 * 75) / (3 * 2) = 18.75
수학식 (2)를 사용하여, 정규화된 악성 일 = (18.75 + 75) / 2 = 46.9
수학식 (1)을 사용하여, 최종 계산된 위험 점수 = (55.1 + 41.5 + 46.9) / 3 = 47.83
위험 점수는 0 내지 100 범위의 값임을 이해해야 한다.
암호화 분석 거래 시각화(CATV)
블록체인 탐색기 애플리케이션을 사용하여 특정 블록체인의 통계 및 거래 이력을 제공할 수 있다. 블록체인 탐색기는 일반적으로 블록을 보고 질의하기 위한 웹 애플리케이션을 지칭한다. 이것은 블록체인에 접속된 웹 브라우저처럼 동작할 수 있다. 블록체인 탐색기를 사용함으로써, 인터넷에 접속된 사용자가 블록체인의 암호화폐 보유자가 만든 모든 거래 또는 상호 작용을 실시간으로 추적할 수 있다. 그러나, 종래의 블록 탐색기 애플리케이션은, 거래가 사이버 범죄 활동을 포함하는지 여부 또는 이러한 자금이 거래되는 장소와 대상을 나타내는 것과 같은 암호화폐 거래의 근본적인 문제를 해결하지 않는다. 사용자가 합법적인 소스로 거래하고 있음을 아는 것이 바람직하므로, 사용자가 사용할 수 있는 위험 표시자 또는 확인이, 임의의 블록체인 거래를 진행하는 데 도움이 될 것이며 자금 세탁 활동을 단념시킬 것이다.
블록체인에서 특정 지갑으로 거래 위험을 결정하도록 구성된 애플리케이션을 제안한다. 이 애플리케이션은, 본 개시 내용에서 암호화 분석 거래 시각화(CATV) 애플리케이션이라고 칭한다. CATV 애플리케이션은 지속적인 가용성, 거래 추적의 용이성, 흐름 시각화, 및 자동화된 관리 프로세스를 제공한다. 이는, CATV 애플리케이션은, 암호화폐 자산에 관한 자금 세탁을 방지하도록 규정 준수 프로세스 또는 KYC(Know-Your-Client) 프로세스의 일부로서 사용될 수 있음을 의미한다. 거래는, 이전에 공개된 위협 평판 데이터베이스(TRDB), 및 고 위험 암호화 어드레스(또는 지갑 어드레스) 및 검증되었거나 악성 활동에 관여하는 것으로 알려진 블랙리스트 어드레스를 자동으로 플래그 표시하도록 구성된 위험 평가 알고리즘(본 개시 내용에서 CARA라고도 함)과 상관될 수 있다. 고 위험 암호화 어드레스는, 위험 평가 알고리즘(즉, CARA 알고리즘)에 의해 악성 위협이 될 가능성이 상당한 것으로 결정된 어드레스로서 정의되는 반면, 블랙리스트에 있는 암호화 어드레스는 악성으로 발견되어 TRDB에 기록되는 어드레스로서 정의된다. 일례로, CATV 애플리케이션은, 조사된 암호화 어드레스(또는 지갑 어드레스)의 개요, 모든 소스 및 목적지 어드레스에 연관된 위험, 암호화 어드레스 주석을 사용자에게 제공할 수 있게끔, 보고 기능을 포함하도록 구성된다.
TRDB와 상호 참조되는 집합 거래 데이터를 사용하여, CATV 애플리케이션은, 수행되는 블록체인 거래의 소스(즉, 소스 지갑)로부터 목적지(목적지 지갑)로의 흐름 시각화를 제공하도록 구성된다. 이는, 특히 노드(또는 지갑)의 어드레스가 사이버 범위에 관련된 경우, 이러한 암호화 자산 펀드(또는 토큰)의 출처와 이러한 암호화 자산 펀드(또는 토큰)가 전송되는 곳에 대한 진실의 소스를 제공하므로, 위험 평가에 있어서 중요하다.
도 24는 암호화 분석 거래 시각화(CATV) 애플리케이션의 시스템 아키텍처 프레임워크의 일례를 도시한다. CATV 애플리케이션은, (모두 도 24에 도시된) 다음 10개의 구성요소 중 하나 이상과 통신하도록 구성된다.
1. 집단 거래 데이터베이스(Collective Transaction Database)(DB): 집단 거래 데이터베이스는, (예를 들어, 구글 클라우드 플랫폼의) 사용가능한 공개 데이터 세트 및/또는 통합된 파트너 데이터 세트로부터 데이터를 취득하는 암호화(즉, 블록체인) 거래 데이터세트를 포함하는 데이터베이스를 지칭한다. 이 데이터베이스는 로컬 서버 또는 클라우드 서버일 수 있다.
2. 공개 암호화 거래 데이터세트(Public Crypto Transaction Dataset): 이 데이터 세트는, 구글 클라우드 및/또는 센티넬 프로토콜에 참여하는 파트너가 제공하는 분석과 같은 사용가능한 공개 데이터세트로부터 수집된 모든 거래 이력을 취득한다.
3. 통합 파트너 거래 API(Integrated Partners Transaction API): 일례로, 제삼자 거래 인터페이스(API)는 CATV 애플리케이션과 함께 통합될 수 있다. 통합 솔루션 파트너는 요청시 API 구독을 통해 거래 데이터세트를 제공할 수 있다. 특히, 거래 리스트는, CATV 애플리케이션이 사용하기에 적합한 특정된 포맷으로 취득될 수 있다. 예를 들어, 시각화 맵을 생성하도록, 특정된 데이터 범위 내에서 수행되는 특정된 지갑으로부터/지갑으로의 홉의 미리 결정된 수의 내의 거래 리스트를 검색할 수 있다. 도 24의 시각화 엔진이 수행하는 세부 사항은 나중에 설명한다.
다시 말하면, CATV 애플리케이션은 두 개의 소스로부터 거래 데이터세트를 수집한다.
* API를 통해 요청시 모든 관련 거래 정보를 제공하는 하나 이상의 통합 파트너로부터의 피드. 이러한 소스는, 더 빠르고 효율적인 데이터 분석을 위해 CATV 애플리케이션에 맞춤화된 전처리된 거래 데이터의 검색을 용이하게 한다.
* 사용가능한 모든 서비스 제공업체에 의해 검색된 공개 거래 데이터세트. 일례로, 가장 인기있는 암호화 데이터세트가 모두 색인된 구글 BigQuery를 사용할 수 있다. 이러한 소스를 통해, CATV 애플리케이션은 연산 비용이 많이 들 수 있는 거래 처리보다는 데이터 분석 전달에 집중할 수 있다.
구글 BigQuery에 의해 리턴되는 결과의 일례는 아래의 표 2에 도시된 바와 같다.
type 유형 Data 데이터
Figure 112020142427231-pct00007
표 2: 구글 BigQuery에 의해 리턴되는 샘플 데이터세이트의 일례
4. 센티넬 포털: 이것은, 암호화 분석 거래 시각화(CATV) 애플리케이션과 상호 작용하도록 인증 액세스 제어가 부여되기 전에 사용자가 등록할 수 있는 웹 기반 프레임워크이다.
5. 위협 평판 DB(TRDB): 앞서 설명한 것처럼, 위협 평판 데이터베이스는, 사기꾼/해커의 암호화(또는 지갑) 어드레스, 랜섬웨어, 악성 URL, 및 악성 파일 해시 등의 집단 손상 표시자(Collective Indicator of Compromises; IOC)를 제공한다. 일례로, TRDB에는, 각각 보안/비악성 기록, 악성 기록, 및 검사 중인 기록을 나타내는 화이트리스트 기록, 블랙리스트 기록, 및 그레이리스트 기록이 있다. 그레이리스트 기록은, 보안 분석가가 검증한 기록을 지칭할 수도 있지만, 그 결과는 악성 지갑/웹사이트 또는 보안 지갑/웹 사이트에 연결되어 있음을 나타내지 않는다.
6. 크라우드소싱된 악성 암호화 어드레스: 이것은, 검사 및 검증을 위해 커뮤니티(또는 개인)가 센티넬 포털을 통해 제출한 암호화 (또는 지갑) 어드레스 또는 어드레스들을 지칭한다. 일례로, 커뮤니티의 일부인 사용자는, 보안 분석가(예를 들어, 센티넬)가 검증할 수 있도록 의심스러운 암호화 어드레스를 보고할 수 있다. 다른 일례로, CATV 애플리케이션은, 다른 웹 사이트에서 알려지고 게시된 새로운 악성 웹사이트를 검색하도록 구성된다. 웹 크롤러를 사용하여 웹사이트로부터 이러한 정보를 검색할 수 있다. 이러한 정보는, 정확한지를 확인하도록 검증용 센티넬에 전송될 수 있다.
7. 위협 사냥 악성 암호화 어드레스: 사내 보안 분석가가 발견한 악성 암호화 (지갑) 어드레스는, 암호화 어드레스가 블랙리스트에 있는 기록으로서 업데이트되기 전에 검출된 악성 암호화 어드레스가 실제로 악성인지 여부를 검증하도록 보안 분석가(예를 들어, 센티넬)를 위해 센티넬 포털을 통해 보고된다.
8. 시각화 엔진: 사용자 입력(예를 들어, 필요한 분석 심도)을 기반으로, 특정된 지갑을 사용한 암호화 거래의 흐름이 시각화 다이어그램에 제시된다. 시각화 엔진에 의해 생성된 시각화 다이어그램의 일례는 도 26에 도시되어 있다. 시각화 다이어그램의 예에는 도 19b 및 도 20a 내지 20f에 있는 맵도 포함한다. 시각화 엔진은, 또한, TRDB와 상호 참조되는 거래 세부 사항을 강조한다.
9. 거래 정규화 엔진: 사용자 입력을 기반으로, CATV 애플리케이션은, TRDB로부터의 주석을 사용하여 검사된 암호화 어드레스의 소스 및 목적지에 대한 심층 세부 정보를 제공하도록 구성된다. 일례로, 도 27을 참조하면, 사용자가 입력한 암호화 어드레스(즉, 검색 중인 암호화 어드레스)와 관련된 모든 노드를 열거하는 거래 표가 제공된다. 거래 테이블을 표시할 수 있다. 또한, (시각화 엔진에 의해 제공되는) 시각화 다이어그램을 제공하여, 거래 표의 정보를 그래픽 방식(예를 들어, 차트, 순서도 등)으로 제시할 수 있다. 거래 정규화 엔진을 사용하면, 정보를 미리 정의된 소정의 포맷으로 제시할 수 있다. 예를 들어, 거래 정규화 엔진은, 거래 테이블 및/또는 시각화 다이어그램에서 소정의 정보를 숨기는 데 사용할 수 있는 사용자 옵션을 통해 표시되는 정보를 정규화(또는 필터링)하여, 간략화된/선택된 보기를 제공한다. 소스 및 목적지 어드레스와 같은 중요한 정보(사용 가능한 경우)는 주석 처리되어, 사용자가 소정 자금(또는 토큰)을 거래한 사람 및/또는 자금이 거래되는 곳을 알 수 있다. 위험 점수는, 또한, 거래 표에 열거된 각 노드에 대해 생성되어 표시될 수 있다.
다른 일례로, 거래 정규화 엔진은, 수행된 분석의 검색 결과 및/또는 통계적 결과를 나타내는 대시보드를 제공할 수 있다. 예를 들어, 거래 수가 가장 많은 상위 5개의 의심스러운 지갑 또는 가장 많은 수의 이더를 가진 상위 5개의 의심스러운 지갑을 사용자에게 강조 표시할 수 있다. 검색 결과에 적용할 다른 필터가 있을 수도 있다.
10. 암호화 분석 위험 평가(CARA) 엔진으로부터의 데이터 피드(CARA는 위에 설명됨): 검색된 거래 데이터세트를 사용하여, CARA 애플리케이션이 시각화 다이어그램을 생성하도록 사용자에 의해 입력되는 암호화 (지갑) 어드레스에 관한 모든 거래의 (CARA 알고리즘에 의해 계산된) 분석 위험 점수를 제공한다. 일례로, 사용자가 CATV 애플리케이션에 의해 생성된 시각화 다이어그램에 표시된 어드레스 위에 마우스를 올려놓거나 마우스를 클릭하면 위험 점수가 나타날 수 있다. 나타날 수 있는 어드레스 라벨의 일례는 도 25에 도시되어 있다. 라벨은, 어드레스를 가진 노드의 전체 어드레스, 식별될 수 있는 노드 정보, 및/또는 노드에 대한 위험 점수를 포함할 수 있다. 일례로, 이러한 라벨을 숨기도록 CATV 애플리케이션에서 사용가능한 옵션을 있다.
도 26과 도 28을 참조하면, 사용자는, 검색 패널(2604)에 입력을 제공함으로써 CATV 애플리케이션에 의해 검색 및 감시될 암호화 (또는 지갑)(즉, 오리진(2606)) 어드레스를 입력한다. 검색 패널(2604)은 시각화 다이어그램(2602)을 생성하도록 검색될 데이터를 입력하기 위한 것이다. 검색 패널(2604)은 다음 검색 필드를 가질 수 있다.
* 배포 깊이(distribution depth; 2608) - 이것은 질의되는 지갑으로부터 다운스트림측으로 자금이나 토큰을 전송하는 것과 관련된 거래를 나타내는 계층/홉의 수를 가리킨다. 각 홉은 두 개의 지갑 간의 거래를 지칭한다. 도 26에서는, 간단한 시각화 다이어그램을 표시하기 위해 배포 깊이를 1(즉, 1홉)로 설정한다. 배포 깊이는 사용자가 원하는 대로 변경될 수 있다. 그러나, 배포 깊이를 더 높은 값(예를 들어, 계산 속도에 따라 5 초과)으로 설정하면, 시각화 다이어그램의 생성 시간이 길어질 수 있다.
* 소스 깊이(2610) - 이것은 질의되는 지갑의 업스트림에서 자금 또는 토큰의 수신과 관련된 거래를 나타내는 계층/홉의 수를 가리킨다. 도 26에서, 소스 깊이는 더 많은 업스트림측 정보를 표시하기 위해 5(즉, 5홉)로 설정되어 있다. 마찬가지로, 소스 깊이를 더 높은 값(예를 들어, 연산 속도에 따라 5 초과)으로 설정하면, 시각화 다이어그램의 생성 시간이 길어질 수 있다.
* 거래 한계값(2612) - 이것은 생성된 시각화 다이어그램이 특정 노드를 표시하기 위해 처리하는 사용자 특정된 거래의 수를 나타낸다. 거래 한계값은, 시각화 다이어그램 생성을 위한 중지 기준으로서 검색 패널을 사용하여 설정될 수 있다. 예를 들어, 사용자가 거래 한계값으로서 2000을 입력하면, 시각화 다이어그램은, 거래가 2000개를 초과하는 노드의 거래를 표시하지 않는다. 2000개보다 많은 거래가 있는 각 노드는, 거래가 표시되지 않는 한, 노드로서 계속 표시될 수 있다. 이 기능은, 시각화 다이어그램을 생성하는 데 걸리는 시간을 줄이고, 사용자가 다이어그램을 더 쉽게 판독할 수 있게 한다.
* 날짜 범위 - 검색 중인 지갑으로부터 파생되는 거래 및 블록체인에서 지갑의 업스트림측 및/또는 다운스트림측 거래를 검색하기 위해 시작 날짜(2614)와 종료 날짜(2616)를 나타내도록 특정된 필드이다. 다른 일례로, 날짜 범위는, 드롭다운 리스트로부터 선택된 필드, 예를 들어, 지난 30일, 지난 6개월, 지난 1년 등일 수 있다.
일례로, 블록체인으로부터 검색되는 거래의 세부 사항은, 먼저 날짜 범위, 이어서 배포 깊이, 및/또는 소스 깊이, 이어서 거래 한계값에 의해 결정된다. 이러한 필드를 기반으로 하는 필터링의 우선순위는 사용자 또는 머신에 의해 미리 특정될 수 있고/있거나 구성될 수 있다.
일단 검색 중인 암호화 어드레스(즉, 질의된 지갑)의 거래가 검색되면, 시각화 다이어그램이 시각화 패널로서 생성된다. 일례로, 질의된 지갑은 이러한 패널에서 오리진으로서 표시된다. 오리진의 정보를 포함하는 라벨은 시각화 다이어그램에 표시될 수 있다. 질의된 지갑으로부터 파생되는 다운스트림측 및 업스트림측 거래에 관련된 하나 이상의 노드는 다음 카테고리 1 내지 9 중 하나 이상으로 분류될 수 있다.
1. 블랙리스트: TRDB의 블랙리스트 기록에 연관된 노드.
2. 화이트리스트: TRDB의 화이트리스트 기록에 연관된 노드.
3. 거래소: 알려진 분산형 거래소에 연관된 노드. 분산형 거래소는 통상적으로 거래소 운영에 대한 중앙 권한을 가진 엔티티에 의해 소유된다. 이 엔티티는, 사용자가 거래소에 입금하는 자금을 보유하고, 거래소에서 발생하는 거래를 관리한다. 이러한 거래는 거래소만 액세스할 수 있는 내부 원장에 기록된다. 의심스러운 활동이 발생하는 경우, 거래소는 소정의 거래를 취소하고 사용자 자산을 동결할 권리가 있다.
4. 분산형 거래소(DEX): TRDB에서 알려진 분산형 거래소에 연관된 노드. 분산형 거래소는 통상적으로 어떠한 엔티티에 의해서도 관리되지 않는다. 이것은 거래를 실행하는 데 필요한 일련의 규칙을 따르며, 이러한 규칙은 블록체인에 존재하는 스마트 계약이라는 것에 설정된다. 이 스마트 계약은, 명령어로 인코딩된 거래를 스마트 계약으로 전송함으로써 사용자가 상호 작용할 수 있는 프로그램과 유사하다. 이런 식으로, X를 Y로 구매하는 사용자는 스마트 계약에 구매 지침과 함께 Y 금액을 전송하고, Y를 위해 X를 판매하는 사용자는 스마트 계약에 판매 지침과 함께 X 금액을 전송하므로, 구매와 판매가 실행된다. 이어서, 프로그램 로직에 따라, 구매자와 판매자 간에 일치가 있는 경우, 거래가 자동으로 실행되고, 양측 당사자는, 거래가 확인되는 즉시 구매 또는 판매한 것을 얻게 된다. 따라서, 이러한 거래가 블록체인에서 실행되는 방식에 대한 중앙 권한이 없다. DEX의 모든 거래는, 블록체인에서 검증되고 되돌릴 수 없는 거래로서 발생한다.
5. 신용사기 지갑: 통합 파트너(예를 들어, 악성/의심스러운 지갑의 정보를 제공하는 신뢰할 수 있는 소스/데이터베이스)가 제공하는 신용사기 기록에 연관되어 있지만 TRDB에서 찾을 수 없는 노드. 이는, 이 노드가 통합 파트너에 의해 라벨 표시됨을 의미한다.
6. 피싱 지갑: 통합 파트너(예를 들어, 악성/의심스러운 지갑의 정보를 제공하는 신뢰할 수 있는 소스/데이터베이스)가 제공하는 피싱 기록에 연관되어 있지만 TRDB에서 찾을 수 없는 노드.
7. 스마트 계약: 알려진 스마트 계약에 연관된 노드. 스마트 계약으로부터의 암호화 자산(예를 들어, 토큰) 이동의 두 가지 예는, 토큰 판매 어드레스 및 예금 지갑에 사용되는 스마트 계약이다.
8. 주석: TRDB로부터의 정보로 주석이 달린 노드. 그러나, 이러한 노드는 TRDB의 블랙리스트 또는 화이트리스트 기록에 연관되지 않는다.
9. 정보를 찾을 수 없음: 카테고리 1 내지 8 중 어느 하나에도 속하지 않는 노드.
다른 예에서, 다른 유형의 노드를 분류하기 위해 CATV 애플리케이션에 의해 생성된 시각화 다이어그램의 범례는, 카테고리 9를 나열하지 않고 카테고리 1 내지 8만 열거할 수 있다. 이러한 예에서, 카테고리 1 내지 8에 속하지 않는 노드에는 라벨이 표시되지 않는다. 이러한 범례(카테고리 9 제외)의 일례가 도 30에 도시되어 있다. 또 다른 예에서, 도 52에 도시된 바와 같이, 한 카테고리는 거래소와 DEX 모두에 대하여 집합적으로 사용될 수 있고, 한 카테고리는 신용사기 지갑과 피싱 지갑에 대하여 집합적으로 사용될 수 있다. 도 52에 도시된 예에서, "정보를 찾을 수 없음" 카테고리는 "태그 없음"으로 라벨 표시된다.
이러한 카테고리들 중 하나 이상은 쉽게 참조하도록 색상으로 구분될 수 있으며, 및/또는 각 카테고리는 범례에 따라 라벨이 표시될 수 있다. 소스 지갑으로부터 목적지 지갑으로의 자금(또는 토큰) 흐름은 화살표가 있는 선으로 표시된다. 화살표 방향은 소스 지갑으로부터 목적지 지갑으로 표시된다는 점에 주목한다. 소스 지갑으로부터의 라인 색상은 소스 지갑과 동일한 색상으로 구성될 수 있다. 라인의 두께는, 소스 지갑과 목적지 지갑 간에 이체되는 암호화폐(또는 토큰)의 양을 결정하도록 구성될 수 있다. 예를 들어, 거래되는 암호화폐의 양이 많을수록, 노드들 간의 라인이 두꺼워진다. 예를 들어, L2로 표시되는 노드들 간에 거래되는 토큰(이 경우 에테르)의 양이 L2로 표시되는 노드들 간에 거래되는 에테르의 양보다 많기 때문에, L2는 도 26에서 L1보다 두껍다.
시각화 다이어그램은, 노드 유형 및 거래 흐름을 쉽게 식별할 수 있는 색상 표현을 포함할 수 있다. 예를 들어, 다음 카테고리 1 내지 9는 다음과 같은 방식으로 색상 코드 및/또는 라벨 표시될 수 있다.
1. 블랙리스트: 검정, 1로 라벨 표시됨
2. 화이트리스트: 흰색, 2로 라벨 표시됨
3. 거래소: 주황색, 3으로 라벨 표시됨
4. 분산형 거래소: 노란색, 4로 라벨 표시됨
5. 신용사기 지갑: 라이트 핑크, 5로 라벨 표시됨
6. 피싱 지갑: 라이트 핑크, 6으로 라벨 표시됨
7. 스마트 계약: 보라색, 7로 라벨 표시됨
8. 주석: 회색, 8로 라벨 표시됨
9. 정보 없음: 녹색 또는 파란색, 9로 라벨 표시됨.
일례에서, 상이한 계층(또는 홉)은 상이한 음영으로 표현될 수 있다. 예를 들어, 질의된 지갑(2606)으로부터의 제1 홉은, 더 어두운 파란색 음영을 갖는 질의된 지갑(2606)으로부터의 제5 홉에 비해 더 밝은 파란색 음영으로 표시된다. 시각화 다이어그램은, 또한, 펀드(또는 토큰)가 질의된 지갑으로 거래되고 질의된 지갑으로부터 나가는 방식으로 표현될 수 있다. 예를 들어 시각화 흐름은 다음 순서 중 하나로 배열될 수 있다.
* 소스 깊이 n... > 소스 깊이 3 > 소스 깊이 2 > 소스 깊이 1 > 오리진 지갑 > 배포 깊이 1 > 배포 깊이 2 > 배포 깊이 3 > ... 배포 깊이 n
* 배포 깊이 n... < 배포 깊이 3 < 배포 깊이 2 < 배포 깊이 1 < 오리진 지갑 < 소스 깊이 1 < 소스 깊이 2 < 소스 깊이 3 < 소스 깊이 n...
일례에서, 시각화 엔진에 의해 생성된 제1 시각화 다이어그램은, 예를 들어, 블록체인 네트워크(예를 들어, 이더리움)에서 네이티브 코인(예를 들어, 이더)을 거래하는 노드를 표시하도록 구성된다. 네이티브 코인의 블록체인 네트워크에서 생성된 특정 이차 토큰을 거래하는 노드를 표시하도록 제2 시각화 다이어그램이 생성될 수 있다. 제2 시각화 다이어그램은 제1 시각화 다이어그램에서 오버레이로서 표시될 수 있다. 두 개 이상의 이차 토큰 유형이 있는 경우, 각 다이어그램이 한 유형의 토큰에 해당하는 더 많은 시각화 다이어그램을 생성하여 오버레이로서 표시할 수 있다. 따라서, 제1 시각화 다이어그램, 제2 시각화 다이어그램 등에 대해 표시할 내용을 제어하기 위한 하나 이상의 검색 패널 및/또는 시각화 설정 패널을 포함할 수 있다.
도 29는 트위터 포스트에 대한 경품 신용사기의 일례를 도시한다. 이 예에서는, 지갑 어드레스
Figure 112020142427231-pct00008
(줄여서 0x25d420)가 질의되고 있다. 질의에 대한 소스 깊이는 0으로 설정되고 (따라서 시각화 설정 패널(2902)에 표시되지 않음), 목적지 깊이는 2로 설정된다. 이 예에서, 질의된 지갑(2606)은, TRDB의 블랙리스트 기록이기 때문에 사람들에게 신용사기 치도록 악성 행위자가 사용하는 (도 29에서와 같이 라벨 표시된) 악성 지갑으로서 검출된다. CATV 애플리케이션에 의해 생성된 시각화 다이어그램(2602)으로부터, 자금이 도 29에서 '9'로 라벨 표시된 중간 지갑으로 이동되었으며 어드레스가
Figure 112020142427231-pct00009
(줄여서 0x293260)임을 알 수 있다. 이 중간 지갑은, 어드레스가 "
Figure 112020142427231-pct00010
"(줄여서 0xf5bec4)인 거래소(도 29에서 '3'으로 라벨 표시됨)와 최종적으로 거래하는 알려진 거래소(이 예에서는 yobit)에 대한 예금 지갑이다.
도 30은 도 29의 '9'로 라벨 표시된 중간 지갑을 질의하는 시각화 다이어그램(2602)을 예시한다. 이 예에서, 소스 깊이 2610은 1로 설정되고, 목적지 깊이 2608은 1로 설정된다. 이 예에서는, 질의된 지갑으로 자금을 전송한 3개의 다른 지갑이 있다(현재 도 30에서 '오리진' 2606으로 표시되어 있다). 예를 들어, 이러한 3개의 지갑이 앞서 공개된 CARA 알고리즘에 의해 의심스러운 지갑으로 분류된 경우, 이러한 높은 위험을 나타내는 위험 점수가 이러한 3개의 지갑 각각에 대해 CATV 애플리케이션에 의해 표시될 수 있다. 이 예에서, 3개의 다른 지갑은, 어드레스가
Figure 112020142427231-pct00011
(줄여서, 0xc29326)인 질의된 지갑과 강력한 관계를 가지고 있으므로, 0.5를 초과하는(0.75 미만) 위험 점수는, CARA 알고리즘에 따라 이러한 3개의 다른 지갑에 할당될 가능성이 높다.
도 31은, 어드레스가 "
Figure 112020142427231-pct00012
"(줄여서, 0xaf1931)이고 날짜 범위가 2019년 3월 28일 내지 2019년 3월 28일인 거래가 있는 지갑을 질의하는 일례를 도시하며, 배포 깊이 2608과 소스 깊이 2610은 각각 0과 2로서 설정된다. 0으로 설정하면, 배포 깊이가 도 31의 시각화 설정 패널에 표시되지 않는다. 특히, 도 31에서 질의되는 지갑은, 스마트 계약을 예금 지갑으로서 사용하는 분산형 거래소 Luno와 관련이 있다. 도 32는, CATV 애플리케이션에 의해 생성된 도 31에 도시된 시각화 다이어그램(2602)의 확대된 부분 또는 확장된 뷰(예를 들어, 마우스 또는 단축키의 제어에 의해 활성화됨)이다. 유리하게는, 사용자가 질의된 지갑과 상호 작용하는 다른 지갑의 관계를 식별하는 것이 가능하다. 예를 들어, 상이한 거래소들은, 암호화 자산을 Luno 거래소의 상이한 예금 지갑 어드레스들(스마트 계약 및 도 32에서 '7'로 라벨 표시됨)로 전송하였다. 도 32에서 '2'로 라벨 표시된 노드는 채굴 풀이고, 또는 다르게는 나노 풀로서 알려져 있다.
도 33은, 관련 당국의 검출을 피하기 위해 텀블링 활동을 거친 악성 지갑(유형 1의 노드에 연관된 라인으로 표시됨)에 연관된 도난당한 자금을 예시하는 일례이다. 이 예에서, 질의된 지갑의 어드레스는,
Figure 112020142427231-pct00013
(줄여서 0xc5d431)이고, 배포 깊이는 4로 설정된다. 소스 깊이가 0으로 설정되어 있으므로, 이 필드는 시각화 설정 패널에 표시되지 않는다. 시각화 설정 패널(2902)의 "그래프 맞춤" 버튼(3302)을 클릭하면, 시각화 다이어그램(2602)이 보기 패널에 맞도록 배치된다. "그래프 맞춤" 버튼이 클릭되면, 시각화 다이어그램(2602)의 전체 패턴이 도 33에 도시된다. 도 34는 도 33의 시각화 다이어그램(2602)의 확대된 부분 또는 확장된 뷰이다. 자금 흐름은 도 34에서 더 명확하게 볼 수 있다. 암호화 자산의 출구 지점도 도 34에서 더 명확하게 볼 수 있다. 특히, 대부분의 거래 라인은, 스위스의 Shapeshift라는 DEX에 연관된 지갑 어드레스
Figure 112020142427231-pct00014
(줄여서, 0x1c39ba)(도 34에서 "4"로 라벨 표시됨)으로 수렴한다.
일례로, 시각화 설정 패널(2902)에는, HVN 숨기기(고 용량 노드) 기능이 제공된다. 고 용량 노드(HVN) 기능은, 검색 패널의 설정을 기반으로 이미 그려진 시각화 다이어그램의 그래프와 상호 작용하기 위한 설정이다. 이 기능은, 생성된 그래프가 매우 큰 경우에 특히 바람직하며, 그 이유는 사용자가 제한된 표시 영역에서 무슨 일이 일어나고 있는지를 확인하기 어려울 수 있기 때문이다. 따라서, 사용자는 몇 개의 노드만 분석하도록 선택할 수 있다. 이는, 목적지 깊이(즉, 순방향 홉 수 제한) 또는 소스 깊이 버튼(즉, 역방향 홉 수 제한)에 대한 설정을 변경함으로써 수행될 수 있다. 소스 깊이가 0으로 설정된 경우, 시각화 다이어그램(예를 들어, 도 29)은 검사 중인 지갑으로부터 전송되는 자금의 흐름만을 나타낸다는 점에 주목한다. 마찬가지로, 목적지 깊이가 0으로 설정되면, 시각화 다이어그램(예를 들어, 도 31)은 검사 중인 지갑으로 전송되는 자금의 흐름 만을 나타낸다.
대안으로, 사용자는 HVN 기능의 임계값 설정을 변경할 수 있다. 특히, HVN 기능은, 소스 노드로의 흐름 경로의 특정된 수 또는 목적지 노드로부터 멀어지는 흐름 경로의 특정된 수보다 많은 수를 각각 비활성화하도록 구성된다. 예를 들어, 도 36에 표시된 예에서와 같이, 사용자가 HVN 기능에 대한 임계값으로서 4를 선택하고 "HVN 숨김" 버튼을 클릭하면, CATV 애플리케이션은 다음과 같은 방식으로 노드를 숨기도록 구성된다.
1. 배포측(검사된 노드의 다운스트림측)에 있는 노드 X가 4개보다 많은 아웃바운드 경로를 갖는다면, CATV 애플리케이션은 노드 X 및 노드 X로부터 나가는 흐름 경로를 숨긴다.
2. 검사된 노드의 소스측 업스트림에 있는 노드 Y가 4개보다 많은 인바운드 경로를 갖는다면, 노드 Y와 노드 Y로 가는 흐름 경로를 숨긴다.
도 35와 도 36은 각각 HVN 기능의 임계값(3502)이 변경될 때 발생하는 것을 예시하는 도면 전후이다. 일단 HVN 기능의 임계값(3502)이 8에서 4로 변경되면, 4개보다 많은 인바운드 경로를 갖고 도 35에 표시된 노드는 도 36에 표시되지 않는다. HVN 기능이 활성화된 시각화 다이어그램에서, 시각화 다이어그램(2602)은 상당히 단순화된다는 것을 이해해야 한다. CATV 애플리케이션은, 일단 HVN 기능의 임계값이 변경되면 표시된 시각화 다이어그램을 리프레시하도록 구성될 수 있다. 또 다른 수정예에서는, 도 52에 도시된 바와 같이, HVN 기능을 고용량 인바운드 노드 숨기기 및 고용량 아웃바운드 노드 숨기기로 더 차별화할 수 있다. 이는 대용량 인바운드 노드와 대용량 아웃바운드 노드를 독립적으로 고려하면서 더 많은 유연성을 허용한다. 도 52에 도시된 바와 같이, 사용자가 가상화 다이어그램의 일부를 확대 또는 축소하거나 문서 증거로서 표시되는 현재 가상화 다이어그램을 저장하는 것을 보조하는 설정이 있을 수 있다.
다른 일례로, 시각화 다이어그램의 두 개 노드 간의 경로를 필터링하는 옵션이 제공될 수 있다. 도 52에 도시된 바와 같이, 사용자는, 줄여서
Figure 112020142427231-pct00015
인 어드레스를 갖는 블랙리스트에 있는 노드 및 경로 필터 기능에 대한 입력으로서 줄여서
Figure 112020142427231-pct00016
인 어드레스를 갖는 거래소 노드를 선택한다. 이러한 "경로 필터" 커맨드의 수신시, CATV 애플리케이션은 선택한 두 개 노드 간의 경로를 강조 표시할 수 있다. 시각화 다이어그램은, 도 52에 비해 도 53에서 훨씬 단순화된 것을 알 수 있다. 도 52 및 도 53에 예시된 이 예에서, 경로 필터 기능은, 블랙리스트에 등록된 지갑 어드레스가 거래소를 통해 현금화되는 방법을 보여줄 수 있다. 또한, 시각화 다이어그램의 노드를 클릭하면, 해당 노드에 연관된 세부 정보(예를 들어, 지갑 정보 및 거래 정보)를 사용자에게 표시할 수 있다.
CATV 애플리케이션에 의해 생성된 시각화 다이어그램이 포함된 보고서는 종래의 거래 분석 도구에 의해 생성된 보고서와 다르다. 종래의 거래 분석 도구는, 비효율적인 거래소의 거래 추적을 포함하여 거래된 위치에 관계없이 암호화 자산의 흐름을 추적하는 데 중점을 둔다. 거래소의 거래 추적은, 거래를 위해 토큰(양호 또는 불량)이 풀링됨에 따라 불량 토큰이 거래된 위치를 추적하기가 어렵기 때문에, 비효율적이다. 또한, 종래의 거래 분석 도구에 의해 생성된 보고서는, 단순하며, 관련성이 없고/거나 구식이 아닐 수 있는 암호화 자산의 주요 소스를 식별할 뿐이다. 예를 들어, MTGOX라는 거래소는 2014년에 가장 큰 투자 회수 사기 중 하나였다. 암호화 자산은, 이미 소유주가 변경되었어야 하지만, 종래의 거래 분석 도구를 사용하여 생성된 현재 보고서(2018/2019년)는, MTGOX를 여전히 암호화 자산의 소스로서 제시하므로 여전히 구식이다. 반대로, CATV 애플리케이션은, 암호화 자산의 자세한 흐름 및 관련된 노드의 정보를 보여주는 (시각화 다이어그램을 포함하는) 보고서를 생성하도록 구성되며, 이는 단순히 암호화 자산의 소스를 나타내는 것보다 더 관련성이 높다. 또한, CATV 애플리케이션은, 교환 거래 추적을 중지하는 기능을 제공하므로 보다 효율적인 도구이다. 일례로, CATV 애플리케이션은, (거래를 나타내는 인바운드 또는 아웃바운드 경로를 표시하지 않고) 단지 교환 노드로서 500개가 넘는 거래를 갖는 노드를 표시하도록 구성된다. 따라서, 게이트웨이(거래소 포함)가, 암호화 자산 흐름을 추적/감시하고 제 때에 중지될 수 있는 악성/의심스러운/매우 의심스러운 거래를 편리하게 식별할 수 있는 유용한 보고서를 생성하기 위한 계층화된 보안으로서 CATV 애플리케이션을 구현하는 것이 유리하다.
지갑 크롤러 시스템(WCS)
전술한 예에서, 지갑 크롤러 시스템(WCS)은, 위협 평판 데이터베이스(TRDB), 즉, 도 1의 데이터베이스(110)에서 주석이 있는 지갑의 수를 수집하고 증가시키도록 추가로 구현될 수 있다. 특히, 거래소가 거래소의 사용자에게 발행한 거래소 지갑 및 사용자 지갑 등의 거래소에 연관된 지갑 관련 정보는, 전술한 거래 추적 도구인 CATV를 보완하는 데 도움이 될 것이다. 유리하게, 사용자는, 어떤 종류의 지갑 돈 또는 토큰이 거래 흐름으로 유입되는지 또는 어떤 종류의 지갑 돈 또는 토큰이 거래 흐름으로부터 유입되는지를 식별할 수 있다면, CATV에 의해 생성된 시각화 다이어그램에서 거래 흐름을 더 잘 이해할 수 있다. 지갑 어드레스의 단순한 표시는 사용자에게 유용한 정보를 제공하지 않는다. 본 개시 내용에서 사용되는 "거래소"라는 용어는, 달리 특정되지 않는 한, 중앙 집중형 지갑 또는 분산형 지갑을 집합적으로 사용하는 분산형 거래소 및 중앙 집중형 거래소를 지칭한다. 한 구성에 있어서, TRDB를 지갑 크롤러 시스템과 연결하기 위해 애플리케이션 프로그래밍 인터페이스(API)를 생성할 수 있다.
분산형 거래소(DEX)는 통상적으로 스마트 계약을 사용하며, 개별 사용자 지갑은 DEX의 스마트 계약과 직접 상호 작용한다. DEX의 몇 가지 예는 EtherDelta 및 Bancor이다. 중앙 집중형 거래소는 일반 지갑이나 스마트 계약을 사용할 수 있다. 중앙 집중형 거래소의 몇 가지 예는 빗썸 및 업비트이다.
개인 사용자 지갑은, 개인이 소유하며, 하드웨어 지갑, 소프트웨어 지갑, MyEtherWallet 등일 수 있다. 사용자 지갑에 대한 개인 키는 사용자 지갑을 소유하는 개인이 보유하고 있으며, 사용자 지갑은 다양한 목적으로, 예를 들어, 트레이딩, 게임, 토큰 저장 등에 사용될 수 있다.
거래소 지갑은, 거래소 소유이며, 중앙 집중형 지갑 또는 분산형 지갑일 수 있다. 일부 예에서, 거래소 지갑은 한 번의 이체에만 사용된다. 거래소 지갑에 대한 개인 키는, 거래소가 보유하고, 사용자 지갑은, 단일 목적, 즉 거래소에서의 거래를 용이하게 하기 위한 것이다.
아래의 표 3은, WCS 내에서 사용되는 다양한 용어 및 본 예에서 사용되는 해당 주석(해당되는 경우)에 대한 안내이다. 이러한 주석은, 위에서 논의한 암호화 분석 거래 시각화(CATV) 애플리케이션에서 사용되며, 위협 평판 데이터베이스(TRDB)에 저장된다. 동일한 주석은, 지갑 크롤러 시스템에 대하여 로컬인 별도의 데이터베이스(이하 지갑 크롤러 DB)에도 저장된다. 지갑 크롤러 DB에 있는 미식별 지갑은 CATV에 정보가 없는 노드라는 점에 주목한다. 이러한 미식별 지갑의 정보는 TRDB에 저장되지 않는다. 이러한 미식별 지갑의 정보는 지갑 크롤러 시스템에 대하여 로컬인 별도의 데이터베이스에 저장될 수 있다. 미식별 지갑은, 일단 식별되면 TRDB에 기록될 수 있다.
용어 설명 예 CATV에 사용되는 주석
거래소 중앙 집중형 거래소 Binace, 업비트 <거래소의 명치>
거래소 소유 지갑 거래소 소유 지갑은,
거래소가 소유하는 모든 지갑(거래소 지갑, 저장, 가스 제공자)을 지칭함		 - -
> 거래소 지갑 거래소가 사용하는 핫 지갑
Figure 112020142427231-pct00017

(Binance 거래소 지갑)		 거래소
> 가스 제공자
Figure 112020142427231-pct00018

(Poloniex 가스 제공자)		 가스 제공자
> 저장 거래소에 의해 콜드 저장으로서 사용되는 어드레스 (콜드 지갑)
Figure 112020142427231-pct00019

(Coinbene 콜드 지갑/저장)		 저장
> 제어기
Figure 112020142427231-pct00020

(빗썸 제어기)		 제어기
지갑 생성자
어드레스		 새로운 사용자 지갑을 생성하도록 거래소에 의해 사용되는 계약/어드레스
Figure 112020142427231-pct00021

(Luno 지갑 생성자 어드레스)		 생성자
사용자 지갑 거래소에 의해 사용되는 입금 지갑. 사용자는, 돈을 이들 지갑에 입금하며, 이어서 일반적으로 임의의 잔액을 거래소 지갑으로 이체함
Figure 112020142427231-pct00022

(Binance 사용자 지갑)		 사용자 지갑
DEX 분산형 거래소 - DEX에 의해 제공되는 사용자 지갑 없음. 스마트 계약은 P2P 거래를 용이하게 함
Figure 112020142427231-pct00023

(Bancor 계약 어드레스)		 DEX
OTC 오버더카운터(
거래소 외부의 트레이딩을 용이하게 하는 엔티티)/에스크로		 OTC
토큰 계약 어드레스 특정 토큰의 모든 로직/계약을 관리하는 토큰 계약의 어드레스
Figure 112020142427231-pct00024

(웁살라 토큰 계약 어드레스)		 토큰 어드레스
미식별 지갑 주석이 없는 지갑 정보가 없는 노드
표 3 : CATV에서 사용하도록 지갑 크롤러 시스템(WCS)에서 사용되는 주석
지갑 크롤러 시스템과 관련하여 설명한 "가스"라는 용어는 이더리움 블록체인 시스템에서 사용되는 특수 단위이다. 이것은 액션 또는 액션 세트에 대해 작업하는 데 연산 자원의 양이 얼마나 필요한지를 측정한다. 예를 들어, 하나의 keccak256 암호화 해시를 계산하려면, 해시가 계산될 때마다 30개의 가스가 필요하며, 해싱되는 데이터의 256비트마다 6개의 추가 가스가 필요하다. 이더리움 플랫폼에 대하여 거래 또는 계약에 의해 수행될 수 있는 모든 연산은, 소정의 수의 가스 비용이 들며, 많은 연산 자원을 필요로 하는 연산은 연산 자원을 거의 필요로 하지 않는 연산보다 많은 가스 비용이 든다.
대부분의 중앙 집중형 거래소는, 사용자 지갑으로부터 수신되는 입금을 처리할 때 2-단계 프로세스/거동을 따르는 것으로 관찰되었다. 관찰된 2-단계 프로세스는 도 38a에 예시되어 있다. 사용자(3802)는, 암호화폐의 금액, 이 경우 이더(3804)를 거래소 X에 의해 제공된 사용자 지갑 어드레스(3805)에 입금한다. 거래소 X는 일반 지갑을 사용하는 중앙 집중형 거래소이다. 사용자 지갑(3805)은 사용자(3802)에 연관되어 있다. 그 후, 사용자 지갑 어드레스(3805)에 입금된 이더(3804)는 거래소 X가 소유하는 핫 지갑(3806)으로 이체된다. 거래소 핫 지갑(3806)은, 또한, 사용자(3808a, 3808y 및 3808z)와 같은 거래소 X의 다른 사용자가 소유하는 다른 사용자 지갑으로부터 암호화폐를 이체하는 데 사용된다. 도 38a에 도시되지 않았지만, 거래소 핫 지갑(3806)은, 인출, 즉 거래소 핫 지갑(3806)으로부터 사용자 지갑(예를 들어, 3805)으로의 암호화폐의 이체에 거의 사용되지 않는다는 점을 이해해야 한다. 인출과 관련된 거래에 있어서, 거래소 핫 지갑은, 층계 지갑으로 돈을 이체하고 중계 지갑을 사용하여 출금을 수행할 가능성이 있다.
예를 들어, 블록체인 탐색기 애플리케이션을 사용하여, 지갑 크롤러 시스템은, 알려진 사용자 지갑 어드레스에 의해 행해진 거래를 크롤링하여 거래소 지갑을 식별할 수 있다. 도 38a와 도 38b에 예시된 예를 사용하여, 사용자(3802)는, 자신의 개별 지갑(3807)(줄여서, 어드레스 0Xbb6b14026136fc를 가짐)으로부터 거래소 X에 의해 제공되는 사용자 지갑(3805)(줄여서, 어드레스 OX64db1b94a0304e를 가짐)으로 0.00160583 이더의 양을 이체한다. 그 후, 사용자 지갑(3805)은 이더를 핫 거래소 지갑(3806)(줄여서, 0X257274276a4e5 어드레스를 가짐)으로 이체한다. 이 경우, 사용자 지갑(3805)은 거래소 X로부터 명령어를 수신하면 이더를 거래소 지갑(3806)으로 이체한다. 통상적으로, 핫 거래소 지갑 어드레스(3806)의 어드레스는, 악성 행위자에 의한 추적 및/또는 해킹을 방지하기 위해 암호화폐의 직접 이체를 수행하도록 사용자(3802)에게 제공되지 않는다.
지갑 크롤러 시스템은, 또한, 더 많은 사용자 지갑을 식별하기 위해 핫 거래소 지갑(3806)(줄여서, 어드레스 OX257274276a4e5를 가짐)의 거래를 다시 크롤링하도록 추가로 구성될 수 있다. 계속해서 도 38b의 예에서, 사용자 지갑(3805)으로부터 거래소 지갑(3806)을 식별한 후, 블록체인 탐색기 애플리케이션을 사용하여 핫 거래소 지갑(3806)으로 인입되는 자금 이체를 식별할 수 있다. 따라서, 도 38c에 예시된 바와 같이, 더 많은 사용자 지갑 어드레스가 식별될 수 있다. 일례로, 줄여서 어드레스 OX2140efd7ba3116을 갖는 지갑(3815)은 거래소-발행된 사용자 지갑으로서 식별되는 지갑이다. 그러나, 지갑(3815)은, 지갑(3815)을 TRDB(110)에 사용자 지갑으로서 저장 및/또는 분류하기 전에 검증 프로세스를 거친다.
마찬가지로, 지갑 크롤러 시스템은, 또한, 블록체인 탐색기 애플리케이션을 사용하여 알려진 중계 지갑의 내향 및 외향 거래를 크롤링(취득)하도록 추가로 구성될 수 있다. 도 38d를 참조하면, 거래소(예를 들어 업비트)의 알려진 중계 지갑(3827)(줄여서, 어드레스 OX0ea27883f916249를 가짐)의 내향 및 외향 거래가 크롤링된다. 이 예에서, 일부 암호화폐는 시간 t1에 지갑(3825)(줄여서, 어드레스 0Xf6230e7e98d2bb를 가짐)으로부터 중계 지갑(3827)으로 전송되었으며, 일부 암호화폐는 시간 t2에 중계 지갑(3827)으로부터 지갑(3823)(줄여서, 어드레스 OX25727276a4e5를 가짐)으로 전송되었다. 이 예에서, 일부 암호화폐는 시간 t7에 업비트 1로서 라벨 표시된 지갑으로부터 중계 지갑(3827)으로 전송되었으며, 일부 암호화폐는 시간 t8에 중계 지갑(3827)으로부터 지갑(3815)(줄여서, 어드레스 OX2140efd7ba3116을 가짐)로 전송되었음을 알 수 있다. 이러한 특성은 사용자 지갑에 의해 행해지는 통상적인 인출 거래를 반영한다. 따라서, 이러한 방식으로, 지갑 크롤러 시스템은, 추가 거래소-발행된 사용자 지갑(3817)(줄여서, 어드레스 OX5521a68d4f8253f를 가짐), 추가 거래소-발행된 사용자 지갑(3821)(줄여서, 어드레스 OX22b84d5ffea8b80을 가짐)，및 추가 거래소 핫 지갑(3825)(줄여서, 어드레스 0Xf6230e7e98d2bb를 가짐)을 식별할 수 있다. 다른 거래소 핫 지갑은 도 38d에서 "upbit1"로 라벨 표시되어 있지만, 이에 연관된 지갑 어드레스가 있다(그러나 도 38d에는 도시되어 있지 않다)．도 38d의 사용자 지갑(3815)은 도 38c에서 논의된 예를 통해 식별된 사용자 지갑이다. 따라서, 크롤링 중에, 지갑 크롤러 시스템은 동일한 사용자 지갑을 식별하고/하거나 지갑을 여러 번 교환할 수 있으므로, 지갑 크롤러 시스템은 중복 기록을 방지하기 위해 TRDB의 데이터를 체크하고 필요한 경우 업데이트하도록 구성될 수 있다.
지갑 크롤러 시스템은, 또한, 사용자 지갑과 상호 작용하는 다른 거래소 지갑 어드레스를 크롤링(취득)하도록 추가로 구성될 수 있다. 도 38e를 참조하면, 블록체인 탐색기 애플리케이션을 사용하여, 사용자 지갑(3829)(줄여서, 어드레스 0Xe4c10e1b6c0c0e를 가짐)의 과거 거래를 취득할 수 있다. 이 예에서, 추가 거래소 지갑(3833)(줄여서, 어드레스 OXOOd7f2709c7b3Q5를 가짐) 및 추가 거래소 지갑(3835)(줄여서, 어드레스 OX2c41b8e152d8fb1을 가짐)이 식별된다.
사용자 지갑은, 개인이 분산형 지갑(예를 들어, Coinbase)으로 중앙 집중형 거래소와 상호 작용할 때도 식별될 수 있다. 사용자 지갑이 분산형 지갑을 사용하여 중앙 집중형 거래소와 상호 작용하는 방법을 보여주는 개략도는 도 44에 도시되어 있다. 그러나, 사용자 지갑은 각 거래 후에 변경될 수 있다. 구체적으로, 사용자 지갑에 입금된 코인은 타인에 의한 인출을 위해 거래소에 의해 사용될 수 있으며, 중계 지갑을 사용하여 사용자 지갑의 (출금 후) 잔액을 거래소로 이동시킬 수 있다. 이러한 거래는 개별 지갑이 DEX와 상호 작용하는 방법을 도시하는 도 46의 개략도에서 볼 수 있다.
일례로, 도 41a를 참조하면, 개인은, t1에 거래소에 의해 제공되는 특정된 사용자 지갑(4105)에 개별 지갑(줄여서, 어드레스 0Xdbb903b977a665를 가짐)으로부터 이더 값 0.02를 입금한다. 이 예에서 특정된 사용자 지갑(4105)의 어드레스는 0Xeafa2b5bed5e4c이다. 사용자 지갑(4105)에 의해 이루어진 거래가 있음을 알 수 있다. t2에서, 사용자 지갑(4105)은 이더 값 0.04를 지갑(4111)(줄여서, 어드레스 0Xbe7fb8c3eccbd8을 가짐)으로 이체한다. t3에서, 사용자 지갑(4105)은 이더 값 0.00859883을 지갑(4109)(줄여서, 어드레스 OX242edd6abb67ec를 가짐)으로 이체한다. t4에서, 사용자 지갑(4105)은 이더 값 0.00541917을 중계 지갑(4107)(줄여서, 어드레스 OX6c839d71cc6916을 가짐)으로 이체한다. 통상적인 중계 지갑은 자금 인출에도 사용할 수 있지만, 인출이 수행될 때마다 중계 지갑이 이동(예를 들어, 분할)된다. 도 42c에 예시된 바와 같이, 이더 값 0.20215127이 줄여서 어드레스 0Xd2a228a61cf14a8을 갖는 중계 지갑(4212)으로부터 인출될 때, 중계 지갑(4212)은 3개의 다른 중계 지갑(4214a, 4214b, 4214c)으로 분할된다. 중계 지갑(4214a, 4214b, 4214c) 각각은 다른 양의 이더로 이체되고 있다.
중계 지갑은 다른 사용자 지갑으로부터의 자금 이체에 연관될 수 있음을 이해해야 한다. 이는 중계 지갑을 통해 추가 사용자 지갑을 식별할 수 있음을 의미한다. 예를 들어, 도 41b를 참조하면, 블록체인 탐색기 애플리케이션을 사용하여, 중계 지갑(4107)의 IN txs(내향 거래)를 취득하면, 추가 사용자 지갑(예를 들어, 어드레스 OX2ed62af7df45f0c를 갖는 사용자 지갑)을 취득할 수 있다.
이제 도 42a를 참조하면, 어드레스 OX869939a578d994를 갖는 지갑에 의해 지갑(4109)(줄여서, 어드레스 OX242edd6abb67ec를 가짐)으로부터 0.00817883의 이더 인출이 이루어졌음을 알 수 있다. 이것은 지갑(4109)이 오직 하나의 IN Tx와 하나의 OUT Tx(외향 거래)만을 가지고 있음을 의미하며, 이러한 관찰은 인출 중계 지갑에서 전형적이다. 출금 중계 지갑은 출금에 한 번만 사용된다는 점에 주목한다. 따라서, 지갑(4109)이 출금 중계 지갑이라고 추론할 수 있다,
이제 도 42b를 참조하면, 가스 결제(ZRX 토큰)로서 다른 사용자 지갑으로 이체가 이루어졌고, 나머지 이더 0.00321716은 어드레스 OX058b022501fe91을 가진 다른 중계 지갑(4210)으로 이체된 것을 알 수 있다.
다른 일례로, 도 42d 내지 도 42g를 참조하면, 센티넬은, 업비트 거래소의 사용자 예금 지갑의 OUT 거래를 취득하여 업비트의 핫 지갑 또는 중계 지갑을 분석할 수 있다. 본 예에서는, 3개의 지갑이 식별되고 있다. 각 지갑이 중계 지갑인지 업비트의 핫 지갑인지를 식별하기 위해, 각 지갑의 거래 이력(예를 들어, 거래 횟수, 잔액)을 취득한다. 도 42e에서 볼 수 있듯이, 처음 두 개의 지갑에는 2개의 거래만이 있고, 지갑에 잔액이 남아 있지 않다. 이것은, 어드레스 OX3CvJQBKizTehMyAtZjKG47aev6kzBhaeJf 및 OX39Ta6Y1hhgqMDWkLVzrfRPUhyXLkyKDNF를 각각 갖는 처음 두 개의 지갑이 일회성 중계 지갑임을 시사한다. 또한, (도 42f에 예시된) 두 번째 지갑의 거래 이력으로부터, 두 번째 지갑이 어드레스 OX14cGRmViAzVKa277gZznBByGZtnrVPQc8Lr을 갖는 세 번째 지갑으로 이체를 행하였음을 알 수 있다. 도 42g를 참조하면, 세 번째 지갑은, 20000개를 초과하는 거래를 갖고 나머지 잔액이 약 738 비트코인이기 때문에, 업비트의 핫 지갑이라고 쉽게 결론을 내릴 수 있다. 업비트 거래소의 핫 지갑이 식별되므로, 지갑 크롤러 시스템은, 업비트 거래소의 더 많은 중계 지갑 및/또는 사용자 예금 지갑을 식별하기 위해 모든 IN 거래를 검색하도록 구성될 수 있다(도 42h 참조).
일반적으로, 지갑 크롤러 시스템은, 이러한 2-단계 거동을 이용하여 아래 지갑들을 식별하는 데 도움을 준다.
1) 거래소 지갑(핫 지갑)
거래소 지갑은 알려진 사용자 지갑을 통해 식별될 수 있다. 알려진 사용자 지갑을 취득하는 한 가지 방법은, 거래소의 서비스에 가입하고 최소 합을 거래소에 의해 제공되는 지갑 어드레스로 이체하는 것이다. 소정의 거래소의 알려진 많은 사용자 지갑이 주석이 없는 특정 어드레스(즉, TRDB에서의 미식별 지갑)로 거래를 시작하면, 해당 어드레스가 해당 거래소의 거래소 지갑일 가능성이 높다. 세부 사항은 도 38a 및 도 38b를 참조하여 논의되었다.
2) 사용자 지갑
주석이 없는 지갑이 거래소 X의 사용자 지갑으로 분류되는 주요 조건은, 주석이 없는 지갑이 해당 거래소 X의 거래소 소유 지갑에만 암호화폐(OUT Tx)를 전송해야 한다는 것이다. 외향 거래(OUT Tx)는 암호화폐가 지갑으로부터 전송됨을 나타낸다. 따라서, 사용자 지갑의 사용자 유효성 검증을 지갑 크롤러 시스템에 의해 수행하여, 분석 후에 센티넬에 의해 거래소 지갑으로 유효성 검증되는 주석이 없는 지갑 또는 알려진 거래소 지갑으로만 이체를 수행하는 사용자 지갑을 빠르게 식별할 수 있다.
그러나, 주석이 없는 지갑, 즉, 사용자 지갑의 경우, 거래소 X의 거래소 소유 지갑이 아닌 다른 지갑과 함께 OUT Tx를 가질 수 있다. 예를 들어, 토큰 스왑 중에, 사용자 지갑은, 거래소 X가 소유하지 않는 토큰 스왑 어드레스로 전송을 행한다. 이러한 경우, 센티넬(예를 들어, 150)은 수동으로 개입해야 한다. 예를 들어, 주석이 없는 사용자와 거래되고 거래소 지갑이 소유하지 않은 어드레스의 내향 거래 및 외향 거래는, 주석이 없는 지갑이 TRDB에 거래소에 의해 발행된 사용자 지갑으로서 기록되어야 하는지 여부를 결정하기 전에, 웁살라 시큐리티의 구성원에 의해 분석되어야 한다. 도 43을 참조하면, 유효성 검증된 사용자 지갑은 TRDB(110)에 저장되고, 이들 지갑은, 거래소 지갑, 바람직하게는 위협 평판 베이스(110)에서 검증되고 저장된 거래소 지갑으로만 이체를 수행한다.
개별 지갑이 DEX와 상호 작용할 수 있는 방법을 보여주는 개략도가 도 45에 도시되어 있다. 앞서 논의했듯이, 개별 사용자 지갑은 통상적으로 DEX의 스마트 계약과 직접 상호 작용한다. 따라서, 개별 사용자 지갑은 스마트 계약과의 상호 작용을 감시함으로써 식별될 수도 있다. 스마트 계약에서 사용되는 일반적인 메소드는, 도 37에 예시된 바와 같이 입금, 거래, 또는 인출 기능으로 크게 분류될 수 있다. 스마트 계약에 사용되는 각 메소드는 통상적으로 메소드 식별자에 연관된다. 도 39에 도시된 예에서, 개인이 EtherDelta와 같은 DEX와 상호 작용하고 개인이 1 ETH의 값을 입금하면, DEX에서 제공하는 스마트 계약 어드레스 "Ox8d12a197cb00d4747a1fe03395095 ce2a5cc6819"를, 수집할 수 있고, 및/또는 블록체인 탐색기 애플리케이션(예를 들어, Etherscan)을 이용하여 추가 분석에 사용할 수 있다. 간단한 개략도는, 예를 들어, 도 37에서 논의된 식별된 메소드 또는 식별되지 않은 메소드를 이용하여 (유효성 검증된 또는 무효화된) 개별 지갑이 DEX와 상호 작용할 수 있는 방법을 도시한다.
지갑 크롤러 시스템의 일례에서, 사용자 지갑은 도 40에 도시된 바와 같이 2-단계 크롤링 검증 프로세스를 통해 식별될 수 있다.
사용자 지갑은 2개의 상이한 소스로부터 크롤링될 수 있다.
1) 거래소 지갑의 IN TX 보기
거래소 지갑의 주요 목적은 사용자 지갑으로부터 자금을 모으는 것이므로, 거래소 지갑의 IN tx를 크롤링함으로써 많은 사용자 지갑을 식별하는 데 도움이 될 수 있다.
도 40을 참조하면, WCS는, 단계 S4001(EP1의 시작)에서 특정 거래소에 연관된 각각의 알려진 거래소 지갑 어드레스에 대한 모든 새로운 내부 거래(즉, IN Tx)를 크롤링하도록 구성된다. 알려진 교환 지갑 어드레스는, TRDB(110)의 주석이 있는 데이터 또는 지갑 크롤러 시스템(WCDB)에 대하여 로컬인 데이터베이스로부터 검색될 수 있다. 내향 거래는, 지갑이 암호화폐를 수신하고 있음을 나타낸다. 새로운 IN Tx는, 암호화폐를 알려진 거래소 지갑으로 전송한 새로운 어드레스를 취득하도록 블록체인 탐색기 애플리케이션(예를 들어, Etherscan)을 사용함으로써 취득될 수 있다. IN Tx는 정기적으로, 즉, 매시간, 매일, 또는 매주 폴링될 수 있음을 이해해야 한다. 블록체인 탐색기 애플리케이션으로부터 리턴되는 결과 수를 줄이기 위해, 마지막 폴링에서 블록체인 탐색기 애플리케이션이 리턴한 최신 결과(거래 블록 식별자)가, WCDB에 저장된 인덱스로부터 다음 폴링을 시작할 수 있도록 WCDB에 저장되기 전에, 플래그 표시되고 인덱싱될 수 있다.
그 후, 각각의 알려진 거래소 지갑 어드레스의 검색된 IN Tx를 처리하여, 각각의 알려진 거래소 지갑 어드레스에 암호화폐를 전송한 지갑 어드레스 리스트를 취득한다. 이어서, 단계 S4003에서 이 지갑 어드레스 리스트를, TRDB(110) 또는 WCDB의 주석 데이터와 비교하여, 주석이 없는 지갑 어드레스 리스트를 취득한다. 이렇게 주석이 없는 지갑 어드레스 리스트는 거래소 지갑에 의해 발행되는 잠재적 사용자 지갑이다. 각 거래소 지갑에 대한 주석이 없는 지갑 어드레스 리스트는, 단계 S4004에서 추가 처리 전에 개별적으로 처리되거나 통합될 수 있다.
단계 S4002에서, 알려진 거래소 지갑의 IN Tx를 폴링하여 취득된 지갑 어드레스 리스트를 TRDB(110) 또는 WCDB의 주석 데이터와 비교하면, 주석이 있는 사용자 지갑 어드레스 리스트도 단계 S4005에서 취득할 수 있다. 단계 S4003 및 S4005는 동시에 처리될 수 있음을 이해해야 한다. 각 거래소 지갑에 대한 주석이 있는 지갑 어드레스 리스트는 단계 S4006에서 재 유효성 검증을 수행하기 전에 개별적으로 처리되거나 통합될 수 있다. 사용자 지갑의 재 유효성 검증은, TRDB 및/또는 WCDB의 데이터 무결성을 유지하고 특정 거래소의 사용자 지갑으로서 잘못 분류(즉, 허위 긍정)되는 것을 줄이기 때문에 바람직하다. 단계 S4006에서 사용자 지갑 재 유효성 검증은 독립적으로 시작될 수도 있다(즉, EP1 시작). 일례로, 지갑 크롤러 시스템은 거래소(예를 들어, 업비트, Binance)가 발행하는 모든 사용자 지갑을 정기적으로 체크하도록 구성될 수 있다. 사용자 지갑 재 유효성 검증이 독립적으로 시작되는 경우(즉, EP1), 고려할 잠재적 사용자 지갑이 없다는 점을 이해해야 한다. (TRDB에 미리 존재하는) 주석이 있는 지갑만이 분석된다.
단계 S4005에서 취득된 주석이 있는 사용자 지갑 어드레스 리스트의 각 사용자 지갑에 대해, (예를 들어, Etherscan과 같은 블록체인 탐색기 애플리케이션을 사용하여) 모든 새로운 OUT tx가 크롤링되고 있다. 예를 들어, 미리 정의된 거래 블록 식별자보다 큰 거래 식별자를 갖는 새로운 거래를 취득함으로써, 주석이 있는 사용자 지갑에 연관된 새로운 거래만이 연산 효율성을 위해 크롤링된다는 점을 이해해야 한다. 일례로, 지갑 크롤러 시스템은, WCDB의 마지막 크롤링에서 주석이 있는 각 사용자 지갑의 마지막 거래의 거래 블록 식별자를 저장하도록 구성되며, 이러한 파라미터는 새로운 거래를 크롤링하는 데 사용된다. WCDB의 거래 블록 식별자는 각 크롤링 후에 업데이트된다는 점을 이해해야 한다.
이에 비해, 단계 S4005에서는, 단계 S4003에서 취득된 주석이 없는 지갑 어드레스 리스트의 각 사용자 지갑에 대해 (예를 들어, Etherscan과 같은 블록체인 탐색기 애플리케이션을 사용하여) 모든 OUT tx가 크롤링된다. 주석이 없는 각각의 지갑 어드레스에 대해 취득된 지갑 어드레스 리스트는, 단계 S4007에서 추가 처리 전에 개별적으로 처리되거나 통합될 수 있다.
다시 말하면, 주석이 없는 지갑 어드레스 리스트와 주석이 있는 지갑 어드레스 리스트의 각각에 대해 각 OUT Tx가 (예를 들어, 블록체인 탐색기를 통해) 크롤링된다. 의심의 여지를 없애기 위해, 주석이 있는 지갑 어드레스 리스트의 각각에 대해서는 새로운 OUT Tx만이 크롤링되는 반면, 주석이 없는 지갑 어드레스 리스트의 각각에 대해서는 모든 OUT Tx가 크롤링된다. 그 다음, 단계 S4007에서, 각각의 주석이 없는 지갑 어드레스 또는 각각의 주석이 있는 사용자 지갑 어드레스의 모든 각 OUT Tx가 조사 중인 거래소(즉, 거래소 E)의 알려진 거래소 지갑과 관련되어 있는지 여부를 결정한다. 단계 S4007에서 주석이 없는 하나의 특정 어드레스의 모든 각 OUT Tx가 거래소 E의 알려진 교환 지갑과 관련되어 있다고 결정되면(즉, 예), 지갑 크롤러 시스템은, 이러한 주석이 없는 어드레스를 거래소 E에 의해 발행된 사용자 지갑(3805)으로서 분류하고 이에 따라 TRDB(110) 및/또는 WCDB를 단계 S4014에서 (최신 거래 블록 식별자와 함께) 새로 식별된 사용자 지갑으로 업데이트하도록 구성된다. 마찬가지로, 단계 S4007에서 주석이 있는 하나의 특정 사용자 지갑 어드레스의 각각의 새로운 OUT Tx가 거래소 E의 알려진 교환 지갑과 관련이 있는 것으로 결정되면(즉, 예)，지갑 크롤러 시스템은, WCDB를 최신 거래 블록 식별자로 업데이트하도록 구성된다. 주석이 있는 사용자 지갑에 변경 사항이 없기 때문에, TRDB(110)에 대한 업데이트는 필요하지 않다. 단계 S4006 및 S4007은 사용자 지갑 검증 프로세스의 시작이다.
단계 S4007에서, 주석이 없는 하나의 특정 어드레스(잠재적 지갑 어드레스) 또는 주석이 있는 하나의 특정 사용자 지갑 어드레스의 모든 각 OUT Tx가 거래소 E의 알려진 거래소 지갑과 관련이 있는 것은 아니라고 결정되면(즉, 단계 S4007에서 아니오)，지갑 크롤러 시스템은, 단계 S4008에서, WCDB에 저장된 데이터를 사용하여, 잠재적 사용자 지갑 어드레스 또는 주석이 있는 사용자 지갑 어드레스의 각 OUT Tx 중 임의의 것이, 주석은 있지만 검사 중인 거래소(즉, 거래소 E)의 거래소 지갑으로서 주석 표기된 것은 아닌 임의의 지갑 어드레스와 일치하는지 여부를 결정하도록 구성된다. 다시 말하면, 지갑 크롤러 시스템은, (새롭게 식별된) 잠재적 사용자 지갑 어드레스. 또는 (WCDB에 저장된) 사용자 지갑 어드레스가 토큰을 TRDB(110)의 주석이 있는 어드레스에 전송하고 있는지 및 상기 주석이 있는 어드레스가 단계 S4001에서 크롤링되고 있는 거래소 지갑(3806)(즉, 거래소 E)의 동일한 엔티티에 속하는 거래소 지갑에 연관되어 있지 않는지를 결정하도록 구성된다.
단계 S4008에서 "예"라고 결정되면, 결정 조건에 맞는 잠재적 사용자 지갑 어드레스 또는 주석이 있는 사용자 지갑 어드레스(즉, 주석이 있는 지갑으로 암호화폐를 전송하지만 거래소 E의 거래소 지갑이 아님)는, 사용자 지갑이 아니라고 결정될 수 있다. 이는, 잠재적 사용자 지갑 어드레스 또는 주석이 있는 사용자 지갑이 거래소 E의 거래소 지갑이 아닌 알려진 외부 어드레스로 토큰을 전송하고 있기 때문이다. 따라서, 잠재적 사용자 지갑 어드레스의 경우에는, 단계 S4009에서 새로 식별된 지갑 어드레스를 TRDB(110) 및 WCDB에 저장하기 전에 "비거래소 지갑"으로 태그 표시된다. 이에 비해, (TRDB 및 WCDB에 저장된) 주석이 있는 사용자 지갑의 경우에는, "비거래소"로 다시 태그 표시되고, 이에 따라 단계 S4009에서 TRDB(110) 및 WCDB에서 업데이트된다.
단계 S4008에서 "아니오"로 결정되면, 지갑 크롤러 시스템은, 단계 S4010에서 거래소 E의 잠재적 거래소 지갑인 주석이 없는 어드레스의 리스트를 취득하도록 구성된다. 단계 S4010에서 취득된 잠재적 거래소 지갑 어드레스 각각에서는, 해당 잠재적 사용자 지갑 어드레스 또는 주석이 있는 사용자 지갑 어드레스가 거래소 E의 지갑 생성자 어드레스에 의해 생성되었는지 여부가 결정된다(S4011). 이는 해당 주석이 있는 사용자 지갑 어드레스의 플래그 creatorAdd를 체크함으로써 수행될 수 있다. 주석이 없는 어드레스(잠재적 사용자 지갑 어드레스)의 경우, 지갑 크롤러 시스템은, 주석이 없는 어드레스가 거래소 E의 지갑 생성자 어드레스에 의해 생성되었는지를 결정하고 이에 따라 플래그 creatorAdd의 값을 설정하도록 구성된다. 이 예에서, 플래그 creatorAdd가 참이면, 해당 지갑은 거래소의 지갑 생성자 어드레스에 의해 생성된다.
단계 S4011에서 주석이 있는 사용자 지갑 어드레스 또는 잠재적 사용자 지갑 어드레스에 대해 플래그 creatorAdd가 참이면, 잠재적 거래소 지갑 어드레스는 거래소 지갑으로 분류되고, TRDB(110)는 단계 S4012에서 거래소 E의 새로 식별된 거래소 지갑을 포함하도록 업데이트된다. 이후, 지갑 크롤러 시스템은, 잠재적 사용자 지갑 어드레스가 TRDB(110) 또는 WCDB에 등록되지 않았다면, 잠재적 사용자 지갑 어드레스를 거래소 E가 발행한 사용자 지갑으로서 주석 표기하도록 구성된다. 이에 비해, 주석이 있는 사용자 지갑 어드레스의 경우에는, (데이터가 변경되지 않았으므로) TRDB 또는 WCDB에 대한 업데이트가 필요하지 않다.
그러나, 주석이 있는 사용자 지갑 어드레스 또는 잠재적 사용자 지갑 어드레스에 대해 플래그 creatorAdd가 거짓인 경우, 잠재적 거래소 지갑 어드레스는, 단계 S4013a에서 웁살라 시큐리티 구성원의 수동 확인을 위해 WCDB에 미식별 리스트로서 저장된다. 지갑 크롤러 시스템은, 또한, 잠재적 사용자 지갑 어드레스가 WCDB에 등록되지 않았다면, 잠재적 사용자 지갑 어드레스를 거래소 E에서 발행한 사용자 지갑으로서 주석 표기하도록 구성된다. 이어서, 단계 S4013b에서 이들 주석이 있는 지갑 어드레스의 검증된 플래그가 "오프"로 설정되고, 단계 S4013c에서 각 잠재적 교환 지갑 어드레스와 각 잠재적 사용자 지갑 어드레스 및/또는 주석이 있는 사용자 지갑 어드레스 간의 관계를 나타내는 표가 WCDB에서 업데이트된다. 이 예에서, 검증된 플래그가 거짓이면, 주석이 있는 사용자 지갑이 사용자 지갑 검증에 실패했음을 나타낸다. 단계 S4013b에서, 검증된 플래그가 "오프"로 설정되고 TRDB에 기록된 것으로 밝혀진 주석이 있는 어드레스가 발견되면, 지갑 크롤러 시스템은 이에 따라 TRDB를 업데이트한다.
예외 처리 및/또는 수동 검증을 허용하기 위해 웁살라 시큐리티에 의해 동작가능한 일부 인터페이스(예를 들어, 도 47의 메뉴)가 있음을 인식해야 한다. 일단 미식별 리스트서 주석이 없는 어드레스의 조사가 완료되면, TRDB(110)는 이에 따라 단계 S4016에서 업데이트된다. 이는, 지갑 어드레스가 사용자 지갑 또는 거래소 지갑으로 검증되지 않았다면, TRDB(110)에 저장되지 않음을 의미한다(즉, WCDB에만 기록된다)．그러나, TRDB(110)의 사용자 지갑 어드레스가 사용자 지갑 재 유효성 검증 프로세스에 실패하면, 이러한 사용자 지갑의 검증된 플래그가 턴오프된다(그러나, 기록은 삭제되지 않는다).
당업자라면, 거래소 지갑에 대한 모든 IN tx가 사용자 지갑으로부터 비롯된 것은 아니라는 점을 쉽게 파악할 수 있다, 예를 들어, 거래소는 거래소 지갑들 간에 자금을 이체하는 것으로 관찰되었다. 다른 일례로, 다른 이유로(예를 들어, 광고) 돈이나 토큰을 거래소 지갑에 직접 잘못 전송하는 개인이 있을 수 있다.
허위 긍정에 대처하기 위해, 지갑 크롤러 시스템은 새로 식별된 사용자 지갑에 대해 사용자 지갑 유효성 체크를 실행한다. 사용자 지갑 유효성 확인 프로세스는 이전에 정교화되었다(예를 들어, 도 40의 EP2).
2) 지갑 생성자 어드레스 살펴보기
지갑 생성자 어드레스는, 새로운 사용자 지갑을 생성하도록 일부 거래소에 의해 사용되는 계약/어드레스이다. 일단 웁살라 시큐리티의 구성원이 이들 어드레스를 수동으로 식별하고 검증하면, 이들 어드레스를 크롤링하여, 생성되는 사용자 지갑의 어드레스를 검색할 수 있다.
이러한 크롤링된 어드레스는 사용자 지갑일 가능성이 매우 높으며, 이러한 지갑 어드레스는 (저장되지 않았다면) TRDB(110) 및 WCDB에 직접 저장될 수 있다. 그러나, 지갑 크롤러 시스템은, 여기에서 더 많은 거래소 지갑을 잠재적으로 식별할 수 있으므로, 이러한 지갑에 대하여 유효성 체크(프로세스의 제2 단계 - 유효성 검증)를 실행하도록 구성될 수 있다. 사용자 지갑의 유효성 검증은 도 40, EP2를 참조하여 자세히 설명한다.
크롤링된 어드레스는 TRDB(110) 및 WCDB에 저장된 사용자 지갑 어드레스와 새로 식별된 어드레스를 모두 포함한다는 점을 이해해야 한다. 이러한 방식으로 식별된 각 사용자 지갑에 대해, 사용자 크롤러 시스템은, 단계 S4006에서 (블록체인 탐색기 애플리케이션으로부터의 데이터를 사용하여) 모든 OUT tx를 크롤링하도록 구성된다.
연산 효율성을 위해, 예를 들어, 미리 정의된 거래 블록 식별자보다 큰 거래 식별자를 가진 새로운 거래를 취득함으로써, TRDB에 주석이 있는 사용자 지갑에 연관된 새로운 거래만이 크롤링된다. 일례로, 지갑 크롤러 시스템은, WCDB에 마지막 크롤링에서 주석이 있는 각 사용자 지갑의 마지막 거래의 거래 블록 식별자를 저장하도록 구성되며, 이러한 파라미터는 새로운 거래를 크롤링하는 데 사용된다. WCDB의 거래 블록 식별자는 각 크롤링 후에 업데이트된다는 점을 이해해야 한다.
단계 S4006에서 각 사용자 지갑에 대해 취득된 지갑 어드레스의 리스트는 개별적으로 처리되거나 추가 처리 전에 통합될 수 있다. 단계 S4006 후의 단계 S4007, S4008, S4009, S4010, S4011, S4012, S4014 및 S4013a-c는, 이들 단계가 위에서 그리고 도 40c를 참조하여 논의되었으므로 다시 논의하지 않는다. 유일한 차이점은, 고려할 잠재적 사용자 지갑이 없고 주석이 있는 지갑이라는 점이다.
따라서, 지갑 크롤러 시스템은, 블록체인 익스플로러 애플리케이션에 의해 제공되는 데이터로부터 거래소에서 발행한 새로운 사용자 지갑 및/또는 새로운 거래소 지갑을 식별할 수 있다. 이러한 정보는, 도 1의 데이터베이스(110)와 같은 위협 평판 데이터베이스(TRDB)에서 주석이 있는 지갑의 수를 증가시킨다. 특히, 거래소가 거래소 사용자에게 발행한 사용자 지갑 및 거래소 지갑 등의 거래소에 연관된 지갑에 관한 정보는, 사용자가 어떤 종류의 지갑 돈 또는 토큰이 해당 지갑으로 유입되는지 또는 어떤 종류의 지갑 돈 또는 토큰이 해당 지갑으로부터 유입되는지를 식별할 수 있다면, 사용자가 CATV에 의해 생성된 시각화 다이어그램에서 거래 흐름을 더 잘 이해하는 데 도움이 된다. 지갑 어드레스의 단순한 표시는 사용자에게 유용한 정보를 제공하지 않는다.
지갑 크롤러 시스템의 주요 기능
지갑 크롤러 시스템의 기능은, 그래픽 사용자 인터페이스(GUI)를 통해 웁살라 시큐리티의 구성원에게 액세스될 수 있다. GUI는 도 47a에 도시된 바와 같이 메뉴로서 제시될 수 있다. 도 47a를 참조하면, 메뉴 상단에서 현재 실행 중인 프로세스/크롤링을 볼 수 있다. 유리하게, 이것은 자원이 동일한 크롤링 질의에 할당되는 것을 방지하는 것이다. 간단히 말해서, 이 기능은, 지갑 크롤러 시스템에 액세스할 수 있는 사용자가 동일한 파라미터를 사용하여 블록체인 거래를 크롤링하지 못하도록 방지하는 것이다.
지갑 크롤러 시스템의 기능은 두 가지 주요 세그먼트(거래소 및 비거래소)로 분리될 수 있다. 일반적으로, 거래소 세그먼트는 중앙 집중형 거래소 관련 지갑을 취득하도록 구성되고, 비거래소 세그먼트는 DEX, 게임 또는 OTC 어드레스와 관련된 것과 같은 비거래소 세그먼트는 DEX, 게이밍, 또는 OTC 어드레스에 관한 지갑 등의 비거래소 지갑을 취득하도록 구성된다. 아래 단락에서는 거래소 세그먼트와 관련된 기능에 대해 설명한다.
사용자 지갑 유효성 체크(도 48)
모든 유효한 사용자 지갑은 상위 거래소의 다른 거래소 소유 지갑에 대하여 OUT tx만을 가져야 한다는 가정에 따라, 지갑 크롤러 시스템은 이 요구 사항을 충족하지 않는 주석이 있는 임의의 사용자 지갑을 식별하는 기능을 내장하고 있다.
크롤링을 통해 취득된 사용자 지갑의 유효성 체크 프로세스 동안, 정상 및 ERC20 OUT 거래가 모두 추적된다. 이를 위해서는 사용자가 크롤링할 거래소 지갑의 세부 사항을 입력해야 한다.
정상적인 OUT 거래를 크롤링하는 동안, TX 값이 0인 거래는 무시된다. 이는 이러한 이체의 목적지가 일반적으로 토큰 계약이며 ERG 토큰 이체를 위한 것이기 때문이다. 토큰 이체의 실제 목적지는 ERC 20 거래를 크롤링할 때 계산된다.
ERC 20 OUT 거래를 크롤링하는 동안, WCS 내에 정의된 스팸 토큰과 관련된 거래는 무시된다(예를 들어, blockwell.ai KYC Casper Token, tinyurl.com/nicetokens)은 무시된다.
(TRDB와 비교함으로써) 주석이 있는 사용자 지갑으로부터 사용자 지갑의 부 거래소의 거래소 소유 지갑으로서 주석이 없는 임의의 목적지 지갑으로 행해진 OUT 거래를 검출하면, 목적지 어드레스는 미식별된 지갑으로서 표시된다. 또한, 사용자 지갑과 미식별 지갑 간의 연관성은 WCS DB에 기록된다(예를 들어, 도 40의 단계 S4013c).
바람직하게, 유효성 체크가 대량으로 수행되는 경우, 지갑 크롤러 시스템은, 효율성을 위해 500개가 넘는 거래가 있는 어드레스에 대한 유효성 체크를 스킵하도록 구성된다. 500개가 넘는 거래가 있는 이들 어드레스는, 메인 메뉴 상의 '사용자 지갑 유효성 체크(Big Tx)'를 통해 액세스함으로써 호출될 수 있는 지갑 크롤러 시스템의 특별 유효성 체크 기능을 통해 또는 웁살라 시큐리티의 구성원에 의해 수동으로 체크될 수 있다(예를 들어, 도 47a의 옵션 24).
유효성 체크가 완료되면, 검사 중인 거래소의 사용자 지갑과 10개 이하의 연관성을 가진 모든 미식별 지갑은 자동으로 '비거래소'로 분류되며, 모든 연관된 사용자 지갑은 포털로 전송되어 분류 해제된다. 이는 이들 지갑의 주석이 '사용자 지갑'에서 '비거래소'로 변경된다는 것을 의미한다(예를 들어, 도 40의 단계 S4009). 그 근거는, 거래소 소유 지갑이 통상적으로 사용자 지갑과 상당한 양의 상호 작용을 한다는 점에 있다. 따라서, 미식별 지갑이 적어도 사용자 지갑과 상호 작용하지 않는다면, 미식별 지갑이 거래소 소유 지갑이 아닐 가능성이 높다고 안전하게 가정할 수 있다. 유리하게는, 허위 긍정을 줄일 수 있다. "10개 이하의 연관성" 조건에서 "10"이라는 값은 머신 러닝을 통해 정의되는 변수일 수 있음을 이해해야 한다.
모든 유효성 체크의 종료시, 포털에 게시되지 않았고 식별되지 않은 지갑과 어떠한 연관성도 없는 모든 사용자 지갑은 포털에 게시된다. 다시 말하면, TRDB의 데이터와 중복되지 않는 유효성 검증된 사용자 지갑만이 게시된다. 사용자 지갑 유효성 검사는 모든 지갑 생성자 또는 거래소 지갑 크롤링의 종료시 자동으로 호출된다는 점을 이해해야 한다. 그러나, 사용자 지갑 유효성 검사는, 메인 메뉴(예를 들어, 도 47a의 옵션 23)에서 '사용자 지갑 유효성 체크(거래소)' 기능을 통해 사용자에 의해 수동으로 호출될 수도 있다. 이는, 필요하다면 데이터 무결성을 보장하기 위해 센티넬이 특정된 거래소의 모든 사용자 지갑에 대하여 유효성 체크를 실행할 수 있게 하는 것이다.
요약하면, '사용자 지갑 유효성 체크' 프로세스를 사용하여 다음을 수행할 수 있다.
1) 새로운 거래소 지갑 식별: 미식별 지갑은 거래소 지갑일 수 있어서, 주석이 있는 사용자 지갑이 유효함을 강화한다.
2) 허위 긍정 사용자 지갑 식별: 미식별 지갑이 비거래소 지갑으로서 검증되는 경우에, 해당 지갑으로 이체되는 주석이 있는 모든 사용자 지갑은 허위 긍정으로서 식별된다.
3) 토큰 계약 어드레스 식별: OUT tx 정보는 토큰 계약 어드레스를 포함할 수 있다.
4) 지갑 관계 추적(지갑 간의 연관성 형성)
M2M 표는 다음 지갑 유형들 간의 거래 관계를 저장하도록 생성된다.
i. 사용자 지갑 <-> 거래소 지갑
ii. 사용자 지갑 <-> 토큰 계약 어드레스
iii. 사용자 지갑 <-> 미식별 지갑
모든 유효성 체크 후에, 웁살라 시큐리티는, 추가 분석을 수행하여 미식별 지갑을 처리할 수 있도록 미식별 지갑에 대한 경고를 받게 된다.
미식별 지갑을 처리하기 위해, 센티넬은 지갑 크롤러 시스템의 '미식별 지갑 처리' 기능에 액세스할 수 있다.
일례로, 이러한 미식별 어드레스가 속한다고 의심되는 거래소의 모든 미식별 어드레스를 보여주는 표, 및 표로부터 수신된 사용자 지갑의 수가 웁살라 시큐리티의 구성원에게 표시된다. 도 49a를 참조하면, 미식별 어드레스 OX2bb97b6cf6ffe53576032c1171ld59bd056830ee는, 식별자 3993을 가지며, Kraken 거래소에 연관된다. 이것은 434개의 사용자 지갑과의 거래를 갖는다. 마찬가지로, 미식별 어드레스 OX097511b9af934c6acb44ba110c24783f57fb4cbb는, 식별자 5625를 가지며, Bitbay 거래소에 연관된다. 이러한 미식별 지갑은 470개의 사용자 지갑과의 거래를 갖는다.
웁살라 시큐리티의 구성원은, 미식별 어드레스 리스트로부터 처리하고자 하는 미식별 지갑의 식별자를 입력해야 한다. 도 49a의 예에 따라, 구성원은 식별자 5625를 갖는 미식별 지갑을 선택한다. 웁살라 시큐리티 구성원의 요청에 따라 선택된 지갑에 대한 보다 자세한 분석도 표시할 수 있다. 예를 들어, 미식별 지갑으로 거래된 사용자 지갑의 어드레스가 표시된다(도 49b 참조)．이러한 정보는, 웁살라 시큐리티 구성원이 미식별 지갑의 처리 방법을 결정하는 데 도움이 될 수 있다. 예를 들어, 미식별 지갑이 많은 수의 사용자 지갑에 연관되어 있는 경우, 이러한 미식별 지갑은 거래소 소유 지갑일 가능성이 높다.
지갑 크롤러 시스템의 한 예에서, 미식별 지갑은 4가지 주요 방법으로 처리될 수 있다. 센티넬은 4가지 액션 중 임의의 하나를 입력할 수 있다. 도 49c에 도시된 바와 같이, 센티넬이 'y'를 입력하면, 미식별 지갑은 거래소 지갑으로서 재분류될 수 있으며, 이 어드레스로 토큰을 전송한 모든 사용자 지갑은 유효한 사용자 지갑으로서 유지된다.
센티넬이 'n'을 입력하면, 미식별 지갑은 거래소 지갑으로서 거부될 수 있으며, 이 어드레스로 전송된 이전에 식별된 모든 사용자 지갑은 사용자 지갑이 될 수 없으므로, 이렇게 식별된 사용자 지갑은 "비거래소 지갑"으로서 다시 주석 표기된다. 센티넬이 'nv'를 입력하면, 미식별 지갑은 거래소 지갑으로서 거부되지만, 이 어드레스로 전송된 사용자 지갑은 여전히 유효하다. 이 옵션은 미식별 지갑이 토큰 스왑용인 경우에 적용될 수 있다. 대안으로, 센티넬이 결정을 내리지 않았기 때문에 "1"을 입력함으로써 미식별 지갑이 리스트에 남아 있을 수 있다.
스팸 어드레스가 사용자 지갑으로서 잘못 식별되는 것을 방지하기 위해, 지갑 크롤러 시스템은, 거래소 지갑 IN을 통해 사용자 지갑을 크롤링하는 동안 blockwell.ai와 같은 스팸 토큰과 관련된 소정의 거래를 무시하도록 구성된다. 그러나, 일부 스팸 브로드캐스트 어드레스가 캡처되는 경우, 이러한 스팸 어드레스에 대해 유효성 체크 프로세스가 수행될 때 지갑 크롤러 시스템에 의해 이러한 스팸 어드레스를 검출할 수 있다.
이들 지갑에서 유효성 체크를 실행하면, 많은 미식별 OUT 지갑이 (스팸 어드레스이기 때문에) 발견된다. 예를 들어, 도 50에 도시된 바와 같이, ElectrifyAsia에 연관된 스팸 어드레스에 연관된 총 133,406개의 거래가 있다. KYC Casper 토큰의 스팸 어드레스와 관련된 다른 예는 도 51에 도시되어 있다.
지갑 크롤러 시스템은, 센티넬이 스팸 어드레스(들)를 플래그 표시할 수 있도록 구성된다. 일례로, 센티넬은 메인 메뉴의 옵션 27을 선택함으로써 이러한 기능을 호출할 수 있다(예를 들어, 도 47a). 스팸 어드레스가 플래그 표시되면, 지갑 크롤러 시스템은 미식별 지갑 리스트로부터 해당 어드레스의 모든 OUT을 제거하도록 구성된다. 그 후, 해당 스팸 어드레스에 대한 잘못된 '사용자 지갑' 주석을 덮어쓰고 기록을 스팸 어드레스로서 수정하기 위한 자동화된 요청도 TRDB로 전송된다. 지갑 크롤러 시스템은, 주석과 지갑 어드레스를 저장하기 위한 별도의 데이터 베이스를 포함할 수 있으며, 이러한 예에서, 센티넬 프로토콜은 실행 중에 별도의 데이터베이스 및/또는 위협 평판 데이터베이스를 참조하도록 구성된다는 점을 이해해야 한다.
블록체인에 대한 가시성을 높이기 위해, 지갑 크롤러 시스템은, 비거래소(개인) 지갑과 다양한 서비스(예를 들어, DEX, 게이밍, OTC)에 속하는 어드레스 간의 연관성을 식별하고 형성하도록 구성된다. 일례로，지갑 크롤러 시스템은, 센티넬이 텍스트 파일을 통해 DEX, OTC, 게이밍, 갬블링 지갑(DOGG)에 대하여 거래를 수행한 것으로 발견된 모든 비거래소 지갑을 센티넬 포털에 입력(게시)할 수 있도록 한다. 예를 들어, 센티넬이 메인 메뉴의 옵션 5(예를 들어, 도 47a)를 선택하면, 지갑 크롤러 시스템이 텍스트 파일을 수신한다.
.text 파일의 포맷은 다음 포맷으로 되어 있다.
Figure 112020142427231-pct00025
몇 가지 예는 다음과 같다.
Figure 112020142427231-pct00026
거래소 지갑 어드레스의 크롤링과 유사하게, DOGG 지갑 어드레스(즉, DEX/OTC/게이밍/갬블링 어드레스)의 IN tx는, 비거래소 지갑을 식별하도록 지갑 크롤러 시스템에 의해 크롤링될 수 있다. 그러나, 이러한 식별된 비거래소 지갑에 대해 유효성 체크를 수행할 필요는 없다.
근거는, 거래소 사용자 지갑이 DOGG 지갑에 대하여 OUT tx를 행할 가능성이 낮기 때문에, OOGG로 전송되는 모든 지갑이 비거래소 지갑이다. 일례로, 지갑 크롤러 시스템은, 취득한 발신자의 어드레스와 OOGG 어드레스 및/또는 거래 중에 호출된 계약의 메소드 ID(예를 들어, 도 39) 간의 관계를 기록하도록 구성된다.
센티넬 프로토콜은, 현재의 사이버 보안 생태계, 특히, 본질적인 감독 부족으로 고통받는 암호화폐 보안 업계를 돕는 효과적인 플랫폼이 될 것으로 예상된다. 센티넬 프로토콜의 새로운 공격 벡터에 대한 선제적 응답은 머신 러닝을 통해 효과적인 것으로 입증되었다. 그러나, 확률에 기반한 위협의 모호성은 여전히 어려운 과제이다. 블록체인의 집단 지성을 이용하여, 센티넬 프로토콜은 암호화폐 보안 문제를 해결하기 위한 보다 효율적인 해결책을 제공한다. 또한, 센티넬 프로토콜은, 올바른 기술을 가진 개인 및/또는 보안 공급업체가 블록체인 업계 및/또는 암호화폐 보안 업계의 분산형 보안을 위해 이 프로토콜에 참여할 수 있는 기회를 제공한다. 결과적으로, 이는, 거래소, 지불, 및 지갑 회사와 같음 암호화폐 업계와 협력하는 많은 당사자에게 더욱 큰 긍정적 효과를 가져온다. 법적 시스템에 의해 보호되거나 보호되지 않을 수 있는 이들 당사자는, 이제 크라우드 소싱에 의해 유지되는 분산형 위협 데이터베이스를 이용함으로써 보다 안전한 환경에서 운영할 수 있다.
위협 평판 데이터베이스를 관리하는 장치(5402), 센티넬이 소유하는 센티넬 장치(5404), 및 센티넬 프로토콜을 이용하는 개인이 소유하는 사용자 장치(5406) 간의 본 개시 내용의 예시적인 일례에 따른 블록체인을 위한 보안 및 지능 플랫폼(SIPB)(예를 들어, 도 1의 100)이 도 54에 예시되어 있다.
장치(5402)는, 연산 장치일 수 있으며, 처리 유닛(5416), 메모리(5418)(예를 들어, 실행가능 명령어(5420)의 로딩을 위한 RAM과 같은 휘발성 메모리)를 포함하지만 이에 한정되지 않는 다수의 개별 구성요소를 포함하며, 실행가능 명령어는, 처리 유닛(5416)의 제어 하에 장치(5402)가 수행하는 기능을 정의한다. 장치(102)는, 또한, 장치가 통신 네트워크(5408)(예를 들어, 인터넷)를 통해 통신할 수 있게 하는 네트워크 모듈(5425)을 포함한다. 사용자 인터페이스(5424)는, 사용자 상호 작용을 위해 제공되며, 예를 들어, 디스플레이 모니터, 컴퓨터 키보드 등과 같은 종래의 연산 주변 장치를 포함할 수 있다. 장치(5402)는 데이터베이스(5426)도 포함할 수 있다. 또한, 데이터베이스(5426)가 서버 장치(5402)에 대하여 로컬이지 않을 수 있음을 이해해야 한다. 데이터베이스(5426)는 클라우드 데이터베이스일 수 있다.
처리 유닛(5416)은, 입력/출력(I/0) 인터페이스(5422)를 통해 컴퓨터 마우스, 키보드/키패드, 디스플레이, 헤드폰 또는 마이크, 비디오 카메라 등과 같은 입력/출력 장치(도면에는 도시되지 않음)에 접속된다. 처리 유닛(5416)의 구성요소들은, 통상적으로 상호 접속된 버스(도 1에는 도시되지 않음)를 통해 당업자에게 알려진 방식으로 통신한다.
처리 유닛(5416)은, 예컨대 인터넷 또는 유선 LAN 또는 WAN 등의 기타 네트워크 시스템에 액세스하도록, 적절한 트랜시버 장치(즉, 네트워크 인터페이스) 또는 적절한 무선 트랜시버를 통해 예를 들어, 네트워크(5408)에, 예를 들어 인터넷에 접속될 수 있다. 장치(5402)의 처리 유닛(5416)은, 또한, 적절한 무선 트랜시버 장치를 거쳐, 예컨대, WiFi 트랜시버, 블루투스 모듈, 이동 통신 세계화 시스템(GSM), 3G, 3.5G, 4G, 이동통신 시스템 등에 적절한 모바일 이동통신 트랜시버를 거쳐, 각 통신 링크(5410, 5412, 5414)를 통해, 하나 이상의 외부 무선 통신 활성화된 사용자 장치(5404) 및 크루 장치(5406)에 접속될 수 있다.
센티넬 장치(5404) 및/또는 사용자 장치(5406)는, 연산 또는 모바일 장치, 예를 들어, 스마트폰, 태블릿 장치, 및 기타 핸드헬드 장치일 수 있다. 하나 이상의 센티넬 장치(5404) 및 하나 이상의 사용자 장치(5406)는, 유선 네트워크, 이동 통신 네트워크 등의 다른 통신 네트워크를 통해 통신할 수 있지만, 명확성을 위해 이들은 도 1에서 생략되어 있다. 연산 또는 이동 장치(5402)에 대해 전술한 시스템 아키텍처 대신, 사용자 장치(5406) 및/또는 장치(5402)는 센티넬 장치(5404)의 시스템 아키텍처를 갖는 연산 또는 이동 장치일 수 있다. 마찬가지로, 연산 또는 이동 장치(5404)에 대해 후술하는 시스템 아키텍처 대신, 센티넬 장치(5404) 및/또는 사용자 장치(5406)는 장치(5402)의 시스템 아키텍처를 갖는 연산 또는 이동 장치일 수 있다.
센티넬 장치(5404)는, 마이크로프로세서(5428)(또는 프로세서), 실행가능 명령어(5432)의 로딩을 위한 메모리(5430)(예를 들어, RAM과 같은 휘발성 메모리)를 포함하지만 이에 한정되지 않는 다수의 개별 구성요소를 포함할 수 있으며, 실행가능 명령어는, 마이크로프로세서(5428)의 제어 하에 센티넬 장치(5404)가 수행하는 기능을 정의한다. 센티넬 장치(5404)는, 또한, 센티넬 장치(5404)가 통신 네트워크(108)를 통해 통신할 수 있게 하는 네트워크 모듈(도면에 도시되지 않음)을 포함한다. 많은 스마트폰과 기타 핸드헬드 장치에서 흔히 볼 수 있는 터치 패널 디스플레이 및 키패드의 형태일 수 있는 사용자 인터페이스(5336)가, 사용자 상호 작용 및 제어를 위해 제공된다. 센티넬 장치(5404)는, 또한, 데이터베이스(도면에 도시되지 않음)를 포함할 수 있지만, 이러한 데이터베이스는, 센티넬 장치(5404)에 대하여 로컬이지 않을 수 있으며, 클라우드 데이터베이스일 수 있다. 센티넬 장치(5404)는, 다수의 다른 I/O(입력/출력) 인터페이스도 포함할 수 있지만, 헤드폰 또는 마이크, 아이덴티티 모듈(SIM) 카드, 플래시 메모리 카드, USB 기반 장치 등과 접속하기 위한 것일 수 있으며, 이들은 이동 장치 사용에 더 적합하다. 장치(5402), 센티넬 장치(5404), 및/또는 사용자 장치(5406)는, 공통 지갑 주석 데이터베이스, 및/또는 블록체인에 있는 위협 평판 데이터베이스(TRDB)에 액세스할 수 있다. 공통 지갑 주석 데이터베이스에 저장된 데이터의 일례는 도 55에 도시되어 있다. 주석 데이터베이스의 주석이 있는 각 지갑 어드레스는, 블록체인 유형(예를 들어, 이더리움 또는 비트 코인), 보안 카테고리(예를 들어, 화이트리스트, 블랙리스트, 또는 그레이리스트), 지갑 어드레스에 연관된 주석 리스트(예를 들어, 거래소, 사용자 지갑, 업비트, 빗썸, 토큰), 및 주석 데이터베이스의 주석이 있는 다른 지갑 어드레스와의 임의의 관계에 연관될 수 있다.
소프트웨어 및 하나 이상의 컴퓨터 프로그램은, 예를 들어, 클라이언트 애플리케이션(예를 들어, 센티넬 프로토콜, CARA, CATV, 트위터 크롤러, 및/또는 지갑 크롤러)을 포함할 수 있고, 예를 들어, 인스턴트 메시징 플랫폼, 오디오/비디오 재생, 인터넷 접근성, 센티넬 장치(5404) 및 사용자 장치(5406)(즉, 운영 체제)의 작동, 네트워크 보안성, 파일 접근성, 데이터베이스 관리를 위한 하나 이상의 소프트웨어 애플리케이션을 추가로 포함할 수 있고, 이러한 애플리케이션은, 통상적으로 데스크톱 또는 휴대용 (이동) 장치에 설치된 애플리케이션이다. 소프트웨어 및 하나 이상의 컴퓨터 프로그램은, CD-ROM과 같은 데이터 저장 매체, 플래시 메모리 캐리어, 또는 하드 디스크 드라이브에 인코딩된 센티넬 장치(5404) 또는 사용자 장치(5406)의 사용자에게 제공될 수 있으며, 예를 들어, 데이터 저장 장치(도 1에는 도시되지 않음)와 같은 상응하는 데이터 저장 매체 드라이브를 사용하여 판독된다. 이러한 애플리케이션 프로그램은, 또한, 네트워크(5408)로부터 다운로드될 수 있다. 애플리케이션 프로그램은, 실행시 처리 유닛(5416) 또는 마이크로프로세서(5428)에 의해 판독 및 제어된다. 프로그램 데이터의 중간 저장은 RAM(5420 또는 5430)을 사용하여 수행될 수 있다. 클라이언트 애플리케이션은 API로서 제공될 수 있으므로, 개인 또는 조직(예를 들어, 암호화폐 지갑 프로젝트, 암호화폐 거래소, 및 보안 공급업체)이 정보를 이용할 수 있다. 대안으로, 클라이언트 애플리케이션은, 정기적으로 또는 실시간으로 클라이언트 애플리케이션에 다운로드된 업데이트와 함께 개인 또는 조직에 로컬로 제공될 수 있다.
또한, 소프트웨어 또는 컴퓨터 프로그램의 하나 이상의 단계는 순차적으로 수행되기보다는 병렬로 수행될 수 있다. 하나 이상의 컴퓨터 프로그램은, 본질적으로 비일시적일 수 있는 임의의 머신 또는 컴퓨터 판독가능 매체에 저장될 수 있다. 컴퓨터 판독가능 매체는, 자기 또는 광학 디스크, 메모리 칩 등의 저장 장치, 또는 범용 컴퓨터나 이동 장치와 인터페이싱하는 데 적합한 다른 저장 장치를 포함할 수 있다. 머신 또는 컴퓨터 판독가능 매체는, 또한, 인터넷 시스템에서 예시된 것과 같은 유선 매체, 또는 무선 LAN(WLAN) 시스템에서 예시된 것과 같은 무선 매체를 포함할 수 있다. 컴퓨터 프로그램은, 이러한 범용 컴퓨터에 로딩되고 실행될 때, 장치가 본원에서 설명하는 예에서의 연산 방법의 단계를 효과적으로 수행하게 한다.
요약하자면, 본 개시 내용의 예들은 다음과 같은 기능을 가질 수 있다.
일례로, 사이버보안 장치(예컨대, 도 1의 100, 도 54의 5420, 5404, 5406)를 제공한다. 이 장치는 프로세서(예를 들어, 도 54의 5418 및 5428)를 포함하고, 프로세서는, i) 타겟 블록체인 시스템에서 서브젝트 어드레스(예를 들어, 도 19b 및 도 20a 내지 도 20f의 1960, 도 26, 도 28 내지 도 31, 도 33, 도 35, 및 도 36의 2606)에 대한 입력을 수신하고, ii) 타겟 블록체인 시스템에서 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 거래의 미리 정해진 수의 홉에 관련된 어드레스들(예를 들어, 도 19b 및 도 20a 내지 도 20f의 1962, 1964, 2002, 2004, 2006, 2008, 2010, 2012, 2014, 2016, 2018)의 리스트를 취득하고, iii) 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 취득된 어드레스들의 리스트 내의 어드레스들의 의심스러운 거래 거동을 식별하고, iv) 의심스러운 거래 거동을 고려하여 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수를 계산하게끔, 장치를 제어하기 위한 메모리(예를 들어, 도 54의 5418 및 5430) 내의 명령어(예를 들어, 도 54의 5420 및 5432)를 실행하도록 구성된다.
장치는, 또한, 취득된 어드레스들의 리스트로부터 서브젝트 어드레스의 업스트림에 있는 서브젝트 어드레스와 직접 거래한 어드레스를 소스 바로 이웃 어드레스(예를 들어, 도 19b, 도 20a 내지 도 20f의 1962)로서 식별하고, 및/또는 취득된 어드레스들의 리스트로부터 서브젝트 어드레스의 다운스트림에 있는 서브젝트 어드레스와 직접 거래된 어드레스를 목적지 바로 이웃 어드레스(예를 들어, 도 19b, 도 20a 내지 도 20f의 1964)로서 식별하고,
이때, 각 홉은, 타겟 블록체인 시스템의 암호화폐의 하나 이상의 토큰의 전달을 포함하는 두 개의 어드레스 간의 거래로서 정의되며,
소스 바로 이웃 어드레스 및/또는 목적지 바로 이웃 어드레스에 대하여 미리 기록된 사이버보안 위협의 정도의 표시자에 기초하여 및/또는 결정된 의심스러운 거래 거동에 기초하여, 각 소스 바로 이웃 어드레스 및/또는 목적지 바로 이웃 어드레스를 사이버보안 위협의 정도의 표시자로 분류하고,
서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 미리 정해진 수의 거래의 홉의 기간에 발생하는 복수의 거래를 하나 이상의 태스크(예를 들어, 도 21, 도 22, 도 23a 내지 도 23c의 태스크 1 내지 태스크 5)의 각각에 할당하고, 이때, 복수의 거래는 서브젝트 어드레스, 소스 바로 이웃 어드레스, 및/또는 목적지 바로 이웃 어드레스 간의 거래를 포함하고,
태스크에 관련된 소스 바로 이웃 어드레스, 및/또는 목적지 바로 이웃 어드레스의 분류에 기초하여 각 태스크를 사이버보안 위협의 정도의 표시자로 분류하고,
하나 이상의 태스크의 분류에 기초하여 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수를 계산하도록 제어가능하다.
선택적으로, 태스크에 할당된 복수의 거래는, 서브젝트 어드레스와 제1 소스 바로 이웃 어드레스 간의 제1 거래부터 시작하여 서브젝트 어드레스와 최종 목적지 바로 이웃 어드레스 간의 최종 거래까지의 거래를 포함할 수 있고, 최종 목적지 바로 이웃 어드레스는, 서브젝트 어드레스와 소스 바로 이웃 어드레스 간의 거래 전에 서브젝트 어드레스와 거래한 어드레스이다.
위험 점수는, 사이버보안 위협의 미리 정해진 높은 정도의 표시자로 분류된 태스크의 수; 사이버보안 위협의 미리 정해진 높은 정도의 표시자로 분류된 하나 이상의 태스크에 관련된 하나 이상의 거래에 관련된 서브젝트 어드레스의 지속시간; 및 서브젝트 어드레스가 거래하였으며 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 취득된 어드레스들의 리스트의 어드레스들로부터 도출되는 하나 이상의 태스크의 토큰의 불량 값의 양에 기초하여 계산될 수 있다.
선택적으로, 장치는, 하나 이상의 소스 바로 이웃 어드레스로부터 수신되는 태스크의 총 입력 토큰량을 계산하고, 하나 이상의 목적지 바로 이웃 어드레스에 전송되는 태스크의 총 출력 토큰량을 계산함으로써, 하나의 태스크에 대하여 고려되는 토큰들의 불량 값의 양을 계산하도록 제어가능하고, 이때, 태스크에서 거래되는 토큰들의 총 절대값은 총 출력 토큰량과 동일하고,
사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 태스크의 하나 이상의 목적지 바로 이웃 어드레스에 전송된 토큰들의 불량값보다 크다는 제1 조건이 충족되면,그리고
사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 거래된 토큰들의 총 절대값 이하라는 제2 조건이 충족되면,
총 입력 불량값과 동일한, 태스크에 대하여 고려된 토큰들의 불량값의 양이 달성되고,
그러나, 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 거래된 토큰들의 총 절대값을 초과하는 제3 조건의 경우에는, 태스크에 대하여 고려된 토큰들의 불량값의 양이 거래된 토큰들의 총 절대값과 동일하고,
그러나, 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 목적지 바로 이웃에 대한 태스크의 토큰들의 총 불량값이 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값보다 큰 제4 조건의 경우에는, 태스크에 대하여 고려된 토큰들의 불량값의 양이, 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 목적지 바로 이웃 어드레스에 대한 태스크의 토큰들의 총 불량값과 동일하다.
위험 점수는, 아래의 제1 등식에 기초하여 계산될 수 있다.
위험 점수 = 평균(정규화된 악성 토큰 + 정규화된 악성 태스크 + 정규화된 악성 일)
여기서, 정규화된 악성 토큰, 정규화된 악성 태스크, 정규화된 악성 일의 각각의 정규화된 악성 값은 아래의 제2 등식에 의해 계산되고,
정규화된 악성 값 = (정규화된 절대 불량값 + 정규화 없는 불량값의 %),
여기서, 토큰, 태스크, 및 일을 포함하는 각 메트릭의 정규화된 절대 불량값은 아래의 제3 등식에 의해 계산되고,
정규화된 절대 불량값 = [(메트릭의 절대 불량값) * (메트릭의 불량값의 %)/(메트릭의 최대 절대 불량값 * 정규화군),
여기서, 토큰, 태스크, 및 날을 포함하는 각 메트릭의 최대 절대 불량값은 머신 러닝에 의해 학습되고,
여기서, 정규화군은, 토큰, 태스크, 및 일을 포함하는 각 메트릭의 불량값의 %에 기초하여 토큰, 태스크, 및 날을 포함하는 각 메트릭의 절대 불량값을 정규화하기 위한 미리 정해진 값이다.
위험 점수 계산에 대한 기능은 도 22를 참조하여 설명한 예에서 찾을 수 있다.
장치는, 또한, 특성에 기초하여 각 태스크를 사이버보안 위협 정도의 표시자로서 정상, 의심스러움, 매우 의심스러움, 또는 악성으로 분류하도록 제어가능하고,
이 특성은,
a) 잔액이 0 토큰이며 모든 소스 바로 이웃 어드레스에 의한 토큰 보유 시간이 1일 이하인, 모든 소스 바로 이웃 어드레스로부터 목적지 바로 이웃 어드레스의 모든 토큰의 즉시 소비; 및/또는
b) 잔액이 O 토큰이며 토큰 보유 시간이 10일 이상인, 상당한 보유 시간 후의 모든 소스 바로 이웃 어드레스부터의 모든 토큰의 소비
중 적어도 하나를 포함한다.
의심스러운 거래 거동은,
i. 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 하나 이상의 거래가 미리 정해진 수의 홉을 갖는지 여부, 및/또는
ii. 어드레스들의 리스트 내의 각 어드레스가 하나 이상의 미리 정해진 거래 볼륨 임계값에 기초하여 저 거래 어드레스 또는 중 거래 어드레스로서 결정된 후에, 미리 정해진 수의 홉에서 저 거래 어드레스 또는 중 거래 어드레스로서 결정된 하나 이상의 어드레스가 토큰들의 응집 또는 분리의 미리 정해진 인자와의 거래에 관련되는지 여부, 및/또는
iii. 어드레스들의 리스트 내의 하나 이상의 어드레스가 토큰들의 응집 또는 분리의 미리 정해진 인자와의 거래에서 관련되는지 여부에 기초하여 식별될 수 있다.
식별되는 의심스러운 거래 거동은,
i. 토큰들의 응집 또는 분리 없이 토큰들의 직접 중계 중, 서브젝트 어드레스와 직접 거래한 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스부터의 거래의 적어도 5개 홉;
ii. 저 거래 어드레스에 의한 토큰들의 분리 또는 응집의 적어도 4개 인자를 갖는 토큰들의 중계 중, 서브젝트 어드레스와 직접 거래한 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 4개 홉;
iii. 중 거래 어드레스에 의한 토큰들의 분리 또는 응집의 적어도 8개 인자를 갖는 토큰들의 중계 중, 서브젝트 어드레스와 직접 거래한 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 4개 홉;
iv. 최소 2개 어드레스와 관련된 토큰들의 분리 또는 응집의 적어도 2개 인자를 갖는 토큰들의 중계 중, 서브젝트 어드레스와 직접 거래한 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 3개 홉; 및/또는
v. 최소 2개 어드레스와 관련되고 거래소 어드레스의 직전 또는 직후에 발생하는 토큰들의 응집 또는 분리의 적어도 10개 인자를 갖는 단일 거래를 포함할 수 있다.
의심스러운 거래 거동에 대한 기능은 도 20a 내지 도 20f를 참조하여 설명한 예에 의해 예시되어 있다.
서브젝트 어드레스로부터 업스트림 또는 다운스트림에 있는 거래의 미리 정해진 수의 홉은 1 내지 8의 범위에 있는 수일 수 있다. 바람직하게, 서브젝트 어드레스로부터 업스트림 또는 다운스트림에 있는 거래의 미리 정해진 수의 홉은 5 또는 6일 수 있다. 이것은 의심스러운 거래 거동을 식별하는 데 장치가 필요로 하는 연산 노력을 줄이기 위한 것이다.
서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 하나 이상의 어드레스의 의심스러운 거래 거동은, 머신 러닝을 거친 트레이닝된 인공 지능 시스템을 사용하여 결정될 수 있다. 예를 들어, 주 성분 분석을 적용하여, 머신 러닝 단계 동안 트레이닝 세트로부터 악성 행위자가 사용하는 상이한 난독화 기술들을 모방하는 특성을 취득할 수 있다.
장치는, 또한, 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 거래의 미리 정해진 수의 홉에 관련된 어드레스들의 리스트 내의 각 어드레스에 대한 마커, 표시된 마커들 간의 토큰 흐름의 방향, 및 표시된 마커들 간에 거래된 토큰의 양을 표시하기 위한 가상화 다이어그램(예를 들어, 도 26의 2602)을 생성하도록 제어가능하다.
선택적으로, 장치는, 또한, 사용자 입력에 기초하여 가상화 다이어그램을 생성하도록 제어가능하고, 사용자 입력은,
i. 가상화 다이어그램에 표시하도록 서브젝트 어드레스(예를 들어, 도 26, 도 28의 2606)의 다운스트림에 있는 거래의 홉의 수를 선택하기 위한 소스 깊이(예를 들어, 도 26, 도 28의 2610);
ii. 가상화 다이어그램에 표시하도록 서브젝트 어드레스의 업스트림에 있는 거래의 홉의 수를 선택하기 위한 배포 깊이(예를 들어, 도 26, 도 28의 2608);
iii. 가상화 다이어그램에서 입력된 토큰의 양을 넘어 거래된 어드레스의 표시를 배제하도록 토큰의 양을 입력하기 위한 거래 한계값(예를 들어, 도 28의 2612);
iv. 가상화 다이어그램에서 시작일과 종료일 간에 발생하는 거래를 갖는 어드레스를 표시하도록 시작일(예를 들어, 도 28의 2614)과 종료일(예를 들어, 도 28의 26116)을 입력하기 위한 날짜 범위(예를 들어, 도 28의 2614, 2616); 및/또는
v. 어드레스 내로의 또는 어드레스로부터의 미리 경해진 수의 토큰 흐름 경로를 초과하는 각 어드레스(예를 들어, 도 35의 3502)의 표시의 비활성화(예를 들어, 도 35의 3504) 중 하나 이상을 포함한다.
장치는 사이버보안 블록체인 시스템의 일부일 수 있고, 사이버보안 블록체인 시스템은, 사이버보안 위협을 검출하도록 배치된, 사용자, 보안 전문가(예를 들어, 도 1의 150), 및/또는 인공 지능 머신에 의해 수집된 사이버보안 위협 데이터를 포함하는 위협 평판 데이터베이스(예를 들어, 도 1의 110)를 포함하고, 장치는, 또한, 장치를 사용하여 서브젝트 어드레스에 대한 위험 점수를 계산할 때 위협 평판 데이터베이스(예를 들어, 본 개시 내용에서 설명하는 TRDB)를 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수로 업데이트하도록 제어가능하다. 각 장치는 사이버보안 블록체인 시스템의 노드로서 간주될 수 있다. 사이버보안 블록체인 시스템의 하나 이상의 노드는, 사이버보안이 손상되고 타겟 블록체인 시스템의 하나 이상의 어드레스가 관련된 사례를 사용자가 보고할 수 있도록 구성되고, 이러한 보고는 유효성 검증을 위해 하나 이상의 지정된 보안 전문가에 의해 액세스가능한 사이버보안 블록체인의 하나 이상의 노드에 전송되며, 유효성 검증 후에, 할당된 사이버보안 위협의 정도와 함께 하나 이상의 어드레스의 기록 또는 기록들은, 할당되는 경우, 위협 평판 데이터베이스에 사이버보안 블록체인 시스템의 데이터 블록으로서 세이브된다.
선택적으로, 가상화 다이어그램에 표시된 각 어드레스는, 위협 평판 데이터베이스의 기록들을 참조한 후에 카테고리와 함께 표시될 수 있고, 카테고리는, 블랙리스트(예를 들어, 도 35에서 "1"로서 라벨 표시됨), 화이트리스트(예를 들어, 도 35에서 "2"로서 라벨 표시됨)，거래소(예를 들어, 도 35에서 "3"으로서 라벨 표시됨)，분산형 거래소(예를 들어, 도 35에서 "4"로서 라벨 표시됨)，신용 사기 관련(예를 들어, 도 35에서 "6"으로서 라벨 표시됨)，피싱 관련(예를 들어, 도 35에서 "5"로서 라벨 표시됨)，스마트 계약에 연관(예를 들어, 도 35에서 "7"로서 라벨 표시됨)，위협 평판 데이터베이스에 정보로 주석 표기(예를 들어, 도 35에서 "8"로서 라벨 표시됨)； 및 이들 카테고리 중 어느 것에도 속하지 않음(예를 들어, 도 35에서 "9"로서 라벨 표시됨) 중 하나이다.
장치는, 또한,
i. 타겟 블록체인 시스템의 새롭게 발견된 어드레스로 위협 평판 데이터베이스를 업데이트하고, 거래소 지갑, 사용자 지갑, 또는 거래소에 의해 사용되는 중계 지갑 중 하나를 그 새롭게 발견된 어드레스에 할당하는 것; 및/또는
ii. 위협 평판 데이터베이스에 저장된 기존의 어드레스를 질의받는 타겟 블록체인 시스템으로부터 새롭게 획득된 정보로 업데이트하는 것을 타겟 블록체인 시스템에 주기적으로 질의하도록 제어가능하다.
선택적으로, 타겟 블록체인 시스템은, 특정 입력 어드레스와 거래된 어드레스들의 리스트를 요청하고, 요청된 어드레스들의 리스트 내의 각 어드레스에 의해 수행된 거래의 수를 요청하고, 요청된 어드레스들의 리스트 내의 각 어드레스의 토큰 잔액량을 요청함으로써, 질의받을 수 있다.
장치는, 또한, 특정 입력 어드레스가 거래소에 연관된 사용자 지갑이고 특정 입력 어드레스가 거래소 지갑 및 새롭게 발견된 어드레스 또는 기존의 어드레스와 거래되었고 알려지면 그리고 새롭게 발견된 어드레스 또는 기존의 어드레스가 특정 입력 어드레스의 동일한 거래소에 의해 발행된 10개의 다른 사용자 지갑과 거래되는 것으로 밝혀지면, 새롭게 발견된 어드레스를 할당하거나 기존의 어드레스의 할당을 거래소 지갑으로 되게끔 업데이트하도록 제어가능하다. 장치는, 또한, 토큰 또는 토큰들이 새롭게 발견된 어드레스 또는 기존의 어드레스로부터 하나 이상의 알려진 거래소 지갑 또는 거래소에 의해 사용되는 하나 이상의 알려진 중계 지갑으로 직접 이체됨이 타겟 블록체인으로의 질의로부터 밝혀지면, 또는, 지갑 생성자가 새롭게 발견된 어드레스 또는 기존의 어드레스를 생성하였고 지갑 생성자가 거래소에 의해 사용되는 것으로 알려짐이 타겟 블록체인으로의 질의로부터 밝혀지면, 새롭게 발견된 어드레스를 할당하거나 기존의 어드레스의 할당을 사용자 지갑으로 되게끔 업데이트하도록 제어가능하다. 장치는, 또한, 새롭게 발견된 어드레스 또는 기존의 어드레스가 하나의 내향 토큰 거래 및 하나의 외향 토큰 거래에 관련되어 새롭게 발견된 어드레스 또는 기존의 어드레스에 대한 잔액이 O 토큰임이 타겟 블록체인으로의 질의로부터 밝혀지면, 또는, 새롭게 발견된 어드레스 또는 기존의 어드레스에 대하여 토큰 인출이 발생하였고 토큰 인출 후에 새롭게 발견된 어드레스 또는 기존의 어드레스에 대하여 임의의 토큰 잔액이 하나의 지갑보다 많은 지갑으로 이체됨이 타겟 블록체인으로의 질의로부터 밝혀지면, 새롭게 발견된 어드레스를 할당하거나 기존의 어드레스의 할당을 거래소에 의해 사용되는 중계 지갑으로 되게끔 업데이트하도록 제어가능하다.
기존 어드레스의 할당 업데이트 또는 새롭게 발견된 어드레스의 할당에 대한 기능은 도 38a 내지 도 38d, 도 40, 도 41a 내지 도 41b, 도 42a 내지 도 42h를 참조하여 설명한 예에서 찾을 수 있다.
장치는, 또한, 명의도용자 트위터 계정 또는 악성 트위트를 검출하도록 제어가능하다.
선택적으로, 장치는,
i. 서브젝트 트위터 계정의 트위터 핸들과 서브젝트 트위터 계정의 프로파일명 간의 공간의 사용시 이상을 검출하고,
ii. 진본 트위터 계정의 알려진 프로파일명과 서브젝트 트위터 계정의 프로파일명 간의 유사성을 검출하고,
iii. 진본 트위터 계정의 알려진 트위터 핸들과 서브젝트 트위터 계정의 트위터 핸들 간의 유사성을 검출하고, 및/또는
iv. 서브젝트 트위터 계정의 프로파일명과 트위터 핸들에 사용되는 키릴 문자의 수의 이상을 검출함으로써,
서브젝트 트위터 계정의 아이덴티티를 인증하도록 제어가능하다.
서브젝트 트위터 계정의 아이덴티티의 진본성에 관하여 전술한 기능은, 도 4, 도 5a 내지 도 5b, 도 6a 내지 도 6c, 도 7, 및 도 8a 내지 도 8e를 참조하여 설명한 예에서 찾을 수 있다.
일례로, 장치는, 서브젝트 트위터 계정의 아이덴티티의 진본성을 나타내는 배지를 서브젝트 트위터 계정의 프로파일명에 근접하게 표시하도록 제어가능하다. 이 기능은 도 17a와 도 17b를 참조하여 설명한 예에서 찾을 수 있다.
선택적으로, 장치는, 또한, 진본 트위터 계정의 새로운 트위트를 폴링하고,
(i) 검색된 새로운 트위트가 악성 콘텐츠를 나타내는 적어도 하나의 미리 정의된 키워드 및 지갑 어드레스를 포함하는 것으로 결정되는 조건;
(ii) 검색된 새로운 트위트가 악성 콘텐츠를 나타내는 적어도 하나의 미리 정의된 키워드 및 유니폼 리소스 로케이터(URL)를 포함하는 것으로 결정되는 조건;
(iii) 검색된 새로운 트위트가 적어도 하나의 URL을 포함하고, URL에 액세스한 후, URL이 악성 콘텐츠를 나타내는 미리 정의된 HTML 소스 코드를 포함하는 것으로 결정되는 조건; 또는
(iv) 검색된 새로운 트위트가 블랙리스트로 되는 미리 결정된 URL 또는 지갑 어드레스를 포함하는 것으로 결정되는 조건
중 적어도 하나의 조건이 충족되면, 검색된 새로운 트위트 각각을 잠재적으로 악성인 트위트 또는 악성 트위트로서 플래그 표시하도록 제어가능하다.
새로운 트위트를 폴링하고 이들을 플래그 표시하는 전술한 기능은, 도 8a와 도 8b, 도 9, 도 10a 및 도 10c를 참조하여 설명한 예에서 찾을 수 있다.
일례로, 장치는, 검색된 새로운 트위트가 잠재적으로 악성인 트위트 또는 악성 트위트임을 나타내는 시각적 표시자를 표시하도록 제어가능하다. 이 기능은 도 18을 참조하여 설명한 예에서 찾을 수 있다.
다른 일례로, 사이버보안 방법을 제공한다. 이 방법은, 타겟 블록체인 시스템에서 서브젝트 어드레스에 대한 입력(예를 들어, 도 19a의 1903)을 수신하는 단계; 타겟 블록체인 시스템에서 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 거래의 미리 정해진 수의 홉에 관련된 어드레스들의 리스트를 취득하는 단계; 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 취득된 어드레스들의 리스트 내의 어드레스들의 의심스러운 거래 거동을 식별하는 단계; 및 의심스러운 거래 거동을 고려하여 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수를 계산하는 단계(예를 들어, 도 19의 1909)를 포함한다.
또 다른 예에서, 사이버 보안을 위한 방법 및 장치를 제공하며, 이 장치는, 사용자, 보안 전문가, 및/또는 인공 지능에 의해 수집된 위협 데이터를 포함하는 위협 평판 데이터베이스를 포함하며, 사용자는, 보안 전문가가 위협 평판 데이터베이스에 데이터 블록으로서 저장하기 전에 유효성을 검증하도록 해킹 및/또는 신용 사기 등의 악성 데이터를 보고할 수 있고, 보안 전문가 또는 사용자는 위협 평판 데이터베이스에 데이터를 제공한 것에 대해 보상을 받는다. 위협 평판 데이터베이스는, 잠재적 보안 위협을 식별할 수 있는 머신 러닝 학습 데이터를 포함할 수 있다. 방법 및 장치는 블록체인 기술에 기반할 수 있다.
의심의 여지를 없애기 위해, 본 발명의 일 양태의 임의의 기능은 본 발명의 다른 임의의 양태에서 이용될 수 있다. 하기 설명에 주어진 예들은 본 발명을 명확하게 하기 위한 것이며 본 발명을 그러한 실시예 자체로 한정하려는 것이 아니라는 점에 주목한다.
명세서 및 청구범위에서, 문맥상 달리 명시하지 않는 한, "포함하는"이라는 용어는, "~로만 구성되는"이라는 의미의 배타적 의미보다는 "~을 적어도 포함하는"이라는 의미에서 단어의 비배타적 의미를 갖는다. 이는, "포함하다", "포함한다" 등의 단어의 다른 형태에 대한 상응하는 문법적 변경에도 동일하게 적용된다.
본 발명을 특정 실시예를 참조하여 구체적으로 도시하고 설명하였지만, 당업자가 이해하는 바와 같이 본 발명의 범위를 벗어나지 않고 실시예의 형태 및 상세에 있어서 다양한 변화를 이룰 수 있다는 점을 당업자라면 이해할 것이다.

Claims (22)

  1. 사이버보안 장치로서,
    타겟 블록체인 시스템에서 서브젝트 어드레스에 대한 입력을 수신하고,
    상기 타겟 블록체인 시스템에서 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 거래의 미리 정해진 수의 홉에 관련된 어드레스들의 리스트를 취득하고,
    상기 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 취득된 어드레스들의 리스트 내의 어드레스들의 의심스러운 거래 거동을 식별하고,
    상기 의심스러운 거래 거동을 고려하여 상기 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수(Risk Score)를 계산하게끔
    상기 장치를 제어하기 위한 메모리 내의 명령어를 실행하도록 구성된 프로세서를 포함하되,
    상기 취득된 어드레스들의 리스트로부터 상기 서브젝트 어드레스의 업스트림에 있는 서브젝트 어드레스와 직접 거래한 어드레스를 소스 바로 이웃 어드레스(immediate source address)로서 식별하고, 및/또는 상기 취득된 어드레스들의 리스트로부터 상기 서브젝트 어드레스의 다운스트림에 있는 서브젝트 어드레스와 직접 거래된 어드레스를 목적지 바로 이웃 어드레스로서 식별하고, 이때, 각 홉이 상기 타겟 블록체인 시스템의 암호화폐의 하나 이상의 토큰의 이체를 포함하는 두 개의 어드레스 간의 거래로서 정의되며,
    상기 소스 바로 이웃 어드레스 및/또는 목적지 바로 이웃 어드레스에 대하여 미리 기록된 사이버보안 위협의 정도의 표시자에 기초하여 및/또는 결정된 의심스러운 거래 거동에 기초하여, 각 소스 바로 이웃 어드레스 및/또는 목적지 바로 이웃 어드레스를 사이버보안 위협의 정도의 표시자로 분류하고,
    상기 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 미리 정해진 수의 거래의 홉의 기간에 발생하는 복수의 거래를 하나 이상의 태스크의 각각에 할당하고, 상기 복수의 거래는 상기 서브젝트 어드레스, 상기 소스 바로 이웃 어드레스, 및/또는 상기 목적지 바로 이웃 어드레스 간의 거래를 포함하고,
    상기 태스크에 관련된 상기 소스 바로 이웃 어드레스, 및/또는 상기 목적지 바로 이웃 어드레스의 분류에 기초하여 각 태스크를 사이버보안 위협의 정도의 표시자로 분류하고,
    상기 하나 이상의 태스크의 분류에 기초하여 상기 서브젝트 어드레스에 대한 상기 사이버보안 위협의 정도를 나타내는 위험 점수를 계산하도록 제어가능한 , 사이버보안 장치.
  2. 삭제
  3. 제1항에 있어서, 상기 태스크에 할당된 복수의 거래는, 상기 서브젝트 어드레스와 제1 소스 바로 이웃 어드레스 간의 제1 거래부터 시작하여 상기 서브젝트 어드레스와 최종 목적지 바로 이웃 어드레스 간의 최종 거래까지의 거래를 포함하고,
    상기 최종 목적지 바로 이웃 어드레스는, 상기 서브젝트 어드레스와 소스 바로 이웃 어드레스 간의 거래 전에 상기 서브젝트 어드레스와 거래한 어드레스이고,
    상기 위험 점수는
    사이버보안 위협의 미리 정해진 높은 정도의 표시자로 분류된 태스크의 수;
    사이버보안 위협의 미리 정해진 높은 정도의 표시자로 분류된 상기 하나 이상의 태스크에 관련된 하나 이상의 거래에 관련된 상기 서브젝트 어드레스의 지속시간; 및
    상기 서브젝트 어드레스가 거래하였으며 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 취득된 어드레스들의 리스트의 어드레스들로부터 도출되는 상기 하나 이상의 태스크의 토큰의 불량 값의 양에 기초하여 계산되는
    , 사이버보안 장치.
  4. 삭제
  5. 제3항에 있어서, 상기 장치는, 하나 이상의 소스 바로 이웃 어드레스로부터 수신되는 태스크의 총 입력 토큰량을 계산하고, 하나 이상의 목적지 바로 이웃 어드레스에 전송되는 태스크의 총 출력 토큰량을 계산함으로써, 하나의 태스크에 대하여 고려되는 토큰들의 불량 값의 양을 계산하도록 제어가능하고,
    상기 태스크에서 거래되는 토큰들의 총 절대값은 상기 총 출력 토큰량과 동일하고,
    사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 상기 태스크의 하나 이상의 목적지 바로 이웃 어드레스에 전송된 토큰들의 불량값보다 크다는 제1 조건이 충족되면, 그리고
    사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 거래된 토큰들의 총 절대값 이하라는 제2 조건이 충족되면,
    총 입력 불량값과 동일한, 상기 태스크에 대하여 고려된 토큰들의 불량값의 양이 달성되고,
    사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값이 거래된 토큰들의 총 절대값을 초과하는 제3 조건의 경우에는, 상기 태스크에 대하여 고려된 토큰들의 불량값의 양이 거래된 토큰들의 총 절대값과 동일하고,
    사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 목적지 바로 이웃에 대한 태스크의 토큰들의 총 불량값이 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 하나 이상의 소스 바로 이웃 어드레스로부터의 태스크의 토큰들의 총 불량값보다 큰 제4 조건의 경우에는, 상기 태스크에 대하여 고려된 토큰들의 불량값의 양이, 사이버보안 위협의 미리 정해진 높은 정도의 표시자를 갖는 상기 하나 이상의 목적지 바로 이웃 어드레스에 대한 태스크의 토큰들의 총 불량값과 동일한, 사이버보안 장치.
  6. 제5항에 있어서, 상기 위험 점수는 아래의 제1 등식에 기초하여 계산되며,
    위험 점수 = 평균(정규화된 악성 토큰 + 정규화된 악성 태스크 + 정규화된 악성 일)
    여기서, 정규화된 악성 토큰, 정규화된 악성 태스크, 정규화된 악성 일의 각각의 정규화된 악성 값은 아래의 제2 등식에 의해 계산되고,
    정규화된 악성 값 = (정규화된 절대 불량값 + 정규화 없는 불량값의 %)
    여기서, 토큰, 태스크, 및 날을 포함하는 각 메트릭의 정규화된 절대 불량값은 아래의 제3 등식에 의해 계산되고,
    정규화된 절대 불량값 = [(메트릭의 절대 불량값) * (메트릭의 불량값의 %)/(메트릭의 최대 절대 불량값 * 정규화군),
    여기서, 토큰, 태스크, 및 날을 포함하는 각 메트릭의 최대 절대 불량값은 머신 러닝에 의해 학습되고,
    여기서, 정규화군은, 토큰, 태스크, 및 날을 포함하는 각 메트릭의 불량값의 %에 기초하여 토큰, 태스크, 및 날을 포함하는 각 메트릭의 절대 불량값을 정규화하기 위한 미리 정해진 값인, 사이버보안 장치.
  7. 제6항에 있어서, 상기 장치는, 또한, 특성에 기초하여 각 태스크를 사이버보안 위협 정도의 표시자로서 정상, 의심스러움, 매우 의심스러움, 또는 악성으로 분류하도록 제어가능하고,
    상기 특성은,
    a) 잔액이 O 토큰이며 모든 소스 바로 이웃 어드레스에 의한 토큰 보유 시간이 1일 이하인, 모든 소스 바로 이웃 어드레스로부터 목적지 바로 이웃 어드레스의 모든 토큰의 즉시 소비; 및/또는
    b) 잔액이 O 토큰이며 토큰 보유 시간이 10일 이상인, 상당한 보유 시간 후의 모든 소스 바로 이웃 어드레스부터의 모든 토큰의 소비
    중 적어도 하나를 포함하는, 사이버보안 장치.
  8. 제7항에 있어서, 상기 의심스러운 거래 거동은,
    상기 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 하나 이상의 거래가 미리 정해진 수의 홉을 갖는지 여부, 및/또는
    상기 어드레스들의 리스트 내의 각 어드레스가 하나 이상의 미리 정해진 거래 볼륨 임계값에 기초하여 저 거래 어드레스 또는 중 거래 어드레스로서 결정된 후에, 상기 미리 정해진 수의 홉에서 저 거래 어드레스 또는 중 거래 어드레스로서 결정된 하나 이상의 어드레스가 토큰들의 응집 또는 분리의 미리 정해진 인자와의 거래에 관련되는지 여부, 및/또는
    상기 어드레스들의 리스트 내의 하나 이상의 어드레스가 토큰들의 응집 또는 분리의 미리 정해진 인자와의 거래에서 관련되는지 여부에 기초하여 식별되는, 사이버보안 장치.
  9. 제8항에 있어서, 식별하기 위한 상기 의심스러운 거래 거동은,
    토큰들의 응집 또는 분리 없이 토큰들의 직접 중계 중, 상기 서브젝트 어드레스와 직접 거래한 상기 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스부터의 거래의 적어도 5개 홉;
    저 거래 어드레스에 의한 토큰들의 분리 또는 응집의 적어도 4개 인자를 갖는 토큰들의 중계 중, 상기 서브젝트 어드레스와 직접 거래한 상기 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 4개 홉;
    중 거래 어드레스에 의한 토큰들의 분리 또는 응집의 적어도 8개 인자를 갖는 토큰들의 중계 중, 상기 서브젝트 어드레스와 직접 거래한 상기 서브젝트 어드레스의 업스트림 또는 다운스트림에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 4개 홉;
    최소 2개 어드레스와 관련된 토큰들의 분리 또는 응집의 적어도 2개 인자를 갖는 토큰들의 중계 중, 상기 서브젝트 어드레스와 직접 거래한 상기 서브젝트 어드레스의 상류 또는 하류에 있는 소스 또는 목적지 바로 이웃 어드레스로부터의 거래의 적어도 3개 홉; 및/또는
    최소 2개 어드레스와 관련되고 거래소 어드레스의 직전 또는 직후에 발생하는 토큰들의 응집 또는 분리의 적어도 10개 인자를 갖는 단일 거래를 포함하는, 사이버보안 장치.
  10. 제9항에 있어서, 상기 서브젝트 어드레스로부터 업스트림 또는 다운스트림에 있는 거래의 미리 정해진 수의 홉은 5 또는 6인, 사이버 보안 장치.
  11. 제10항에 있어서, 상기 서브젝트 어드레스의 업스트림 및/또는 다운스트림에 있는 하나 이상의 어드레스의 의심스러운 거래 거동은, 머신 러닝을 거친 트레이닝된 인공 지능 시스템을 사용하여 결정되는, 사이버보안 장치.
  12. 제11항에 있어서, 상기 장치는, 또한,
    상기 서브젝트 어드레스의 상류 및/또는 하류에 있는 거래의 미리 정해진 수의 홉에 관련된 상기 어드레스들의 리스트 내의 각 어드레스에 대한 마커, 표시된 마커들 간의 토큰 흐름의 방향, 및
    상기 표시된 마커들 간에 거래된 토큰의 양
    을 표시하기 위한 가상화 다이어그램을 생성하도록 제어가능한, 사이버보안 장치.
  13. 제12항에 있어서, 상기 장치는, 또한, 사용자 입력에 기초하여 상기 가상화 다이어그램을 생성하도록 제어가능하고, 상기 사용자 입력은,
    상기 가상화 다이어그램에 표시하도록 상기 서브젝트 어드레스의 다운스트림에 있는 거래의 홉의 수를 선택하기 위한 소스 깊이;
    상기 가상화 다이어그램에 표시하도록 상기 서브젝트 어드레스의 업스트림에 있는 거래의 홉의 수를 선택하기 위한 배포 깊이;
    상기 가상화 다이어그램에서 입력된 토큰의 양을 넘어 거래된 어드레스의 표시를 배제하도록 토큰의 양을 입력하기 위한 거래 한계값;
    상기 가상화 다이어그램에서 시작일과 종료일 간에 발생하는 거래를 갖는 어드레스를 표시하도록 상기 시작일과 종료일을 입력하기 위한 날짜 범위; 및/또는
    상기 어드레스 내로의 또는 상기 어드레스로부터의 미리 정해진 수의 토큰 흐름 경로를 초과하는 각 어드레스의 표시의 비활성화
    중 하나 이상을 포함하는, 사이버보안 장치.
  14. 제13항에 있어서, 상기 장치는 사이버보안 블록체인 시스템의 일부이고, 사이버보안 블록체인 시스템은, 사이버보안 위협을 검출하도록 배치된, 사용자, 보안 전문가, 및/또는 인공 지능 머신에 의해 수집된 사이버보안 위협 데이터를 포함하는 위협 평판 데이터베이스를 포함하고, 상기 장치는, 또한, 상기 장치를 사용하여 상기 서브젝트 어드레스에 대한 위험 점수를 계산할 때 상기 위협 평판 데이터베이스를 상기 서브젝트 어드레스에 대한 사이버보안 위협의 정도를 나타내는 위험 점수로 업데이트하도록 제어가능하고,
    상기 사이버보안 블록체인 시스템의 하나 이상의 노드는, 사이버보안이 손상되고 타겟 블록체인 시스템의 하나 이상의 어드레스가 관련된 사례를 사용자가 보고할 수 있도록 구성되고, 이러한 보고는 유효성 검증을 위해 하나 이상의 지정된 보안 전문가에 의해 액세스가능한 상기 사이버보안 블록체인의 하나 이상의 노드에 전송되며,
    유효성 검증 후에, 할당된 사이버보안 위협의 정도와 함께 하나 이상의 어드레스의 기록 또는 기록들은, 할당되는 경우, 상기 위협 평판 데이터베이스에 상기 사이버보안 블록체인 시스템의 데이터 블록으로서 세이브되는, 사이버보안 장치.
  15. 제14항에 있어서, 상기 가상화 다이어그램에 표시된 각 어드레스는, 상기 위협 평판 데이터베이스의 기록들을 참조한 후에 카테고리와 함께 표시되고, 상기 카테고리는, 블랙리스트, 화이트리스트, 거래소, 분산형 거래소, 신용 사기 관련, 피싱 관련, 스마트 계약에 연관, 위협 평판 데이터베이스에 정보로 주석 표기; 및 이들 카테고리 중 어느 것에도 속하지 않음 중 하나인, 사이버보안 장치.
  16. 제15항에 있어서, 상기 장치는, 또한,
    상기 타겟 블록체인 시스템의 새롭게 발견된 어드레스로 위협 평판 데이터베이스를 업데이트하고, 거래소 지갑, 사용자 지갑, 또는 거래소에 의해 사용되는 중계 지갑 중 하나를 상기 새롭게 발견된 어드레스에 할당하는 것; 및/또는
    상기 위협 평판 데이터베이스에 저장된 기존의 어드레스를 질의받는 상기 타겟 블록체인 시스템으로부터 새롭게 획득된 정보로 업데이트하는 것을
    상기 타겟 블록체인 시스템에 주기적으로 질의하도록 제어가능한, 사이버보안 장치.
  17. 제16항에 있어서, 상기 타겟 블록체인 시스템은,
    특정 입력 어드레스와 거래된 어드레스들의 리스트를 요청하고, 요청된 어드레스들의 리스트 내의 각 어드레스에 의해 수행된 거래의 수를 요청하는 것, 및
    상기 요청된 어드레스들의 리스트 내의 각 어드레스의 토큰 잔액량을 요청하는 것을 질의받는, 사이버보안 장치.
  18. 제17항에 있어서, 상기 장치는, 또한,
    특정 입력 어드레스가 거래소에 연관된 사용자 지갑이고 상기 특정 입력 어드레스가 거래소 지갑 및 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스와 거래되었고 알려지면 그리고 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스가 상기 특정 입력 어드레스의 동일한 거래소에 의해 발행된 10개의 다른 사용자 지갑과 거래되는 것으로 밝혀지면, 상기 새롭게 발견된 어드레스를 할당하거나 상기 기존의 어드레스의 할당을 거래소 지갑으로 되도록 업데이트하고, 또는,
    토큰 또는 토큰들이 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스로부터 하나 이상의 알려진 거래소 지갑 또는 거래소에 의해 사용되는 하나 이상의 알려진 중계 지갑으로 직접 이체됨이 상기 타겟 블록체인으로의 질의로부터 밝혀지면, 또는, 지갑 생성자가 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스를 생성하였고 상기 지갑 생성자가 거래소에 의해 사용되는 것으로 알려짐이 상기 타겟 블록체인으로의 질의로부터 밝혀지면, 상기 새롭게 발견된 어드레스를 할당하거나 상기 기존의 어드레스의 할당을 사용자 지갑으로 되도록 업데이트하고, 또는,
    상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스가 하나의 내향 토큰 거래 및 하나의 외향 토큰 거래에 관련되어 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스에 대한 잔액이 O 토큰임이 상기 타겟 블록체인으로의 질의로부터 밝혀지면, 또는, 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스에 대하여 토큰 인출이 발생하였고 상기 토큰 인출 후에 상기 새롭게 발견된 어드레스 또는 상기 기존의 어드레스에 대하여 임의의 토큰 잔액이 하나의 지갑보다 많은 지갑으로 이체됨이 상기 타겟 블록체인으로의 질의로부터 밝혀지면, 상기 새롭게 발견된 어드레스를 할당하거나 상기 기존의 어드레스의 할당을 거래소에 의해 사용되는 중계 지갑으로 되게끔 업데이트하도록 제어가능한, 사이버보안 장치.
  19. 제18항에 있어서, 상기 장치는, 또한, 명의도용자 트위터 계정 또는 악성 트위트를 검출하도록 제어가능한, 사이버보안 장치.
  20. 제19항에 있어서, 상기 장치는, 또한,
    서브젝트 트위터 계정의 트위터 핸들과 상기 서브젝트 트위터 계정의 프로파일명 간의 공간의 사용시 이상을 검출하고, 진본 트위터 계정의 알려진 프로파일명과 상기 서브젝트 트위터 계정의 프로파일명 간의 유사성을 검출하고, 진본 트위터 계정의 알려진 트위터 핸들과 상기 서브젝트 트위터 계정의 트위터 핸들 간의 유사성을 검출하고, 상기 서브젝트 트위터 계정의 프로파일명과 트위터 핸들에 사용되는 키릴 문자의 수의 이상을 검출함으로써, 서브젝트 트위터 계정의 아이덴티티를 인증하고,
    상기 서브젝트 트위터 계정의 아이덴티티의 진본성을 나타내는 배지를 상기 서브젝트 트위터 계정의 프로파일명예 근접하게 표시하도록 제어가능한, 사이버보안 장치.
  21. 제20항에 있어서, 상기 장치는, 또한,
    진본 트위터 계정의 새로운 트위트를 폴링하고,
    (i) 검색된 새로운 트위트가 악성 콘텐츠를 나타내는 적어도 하나의 미리 정의된 키워드 및 지갑 어드레스를 포함하는 것으로 결정되는 조건; (ii) 상기 검색된 새로운 트위트가 악성 콘텐츠를 나타내는 적어도 하나의 미리 정의된 키워드 및 유니폼 리소스 로케이터(URL)를 포함하는 것으로 결정되는 조건; (iii) 상기 검색된 새로운 트위트가 적어도 하나의 URL을 포함하고, 상기 URL에 액세스한 후, 상기 URL이 악성 콘텐츠를 나타내는 미리 정의된 HTML 소스 코드를 포함하는 것으로 결정되는 조건; 또는 (iv) 상기 검색된 새로운 트위트가 블랙리스트로 되는 미리 결정된 URL 또는 지갑 어드레스를 포함하는 것으로 결정되는 조건 중 적어도 하나의 조건이 충족되면, 검색된 새로운 트위트 각각을 잠재적으로 악성인 트위트 또는 악성 트위트로서 플래그 표시하고,
    검색된 새로운 트위트가 잠재적으로 악성인 트위트 또는 악성 트위트임을 나타내는 시각적 표시자를 표시하도록 제어가능한, 사이버보안 장치.
  22. 삭제
KR1020207037735A 2019-01-18 2019-12-31 사이버보안 장치 및 방법 KR102478132B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
SG10201900481T 2019-01-18
SG10201900481T 2019-01-18
SG10201903000R 2019-04-03
SG10201903000R 2019-04-03
SG10201909196V 2019-10-01
SG10201909196V 2019-10-01
PCT/SG2019/050653 WO2020149790A1 (en) 2019-01-18 2019-12-31 Apparatus and method for cybersecurity

Publications (2)

Publication Number Publication Date
KR20210014155A KR20210014155A (ko) 2021-02-08
KR102478132B1 true KR102478132B1 (ko) 2022-12-15

Family

ID=71613803

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020207037735A KR102478132B1 (ko) 2019-01-18 2019-12-31 사이버보안 장치 및 방법

Country Status (4)

Country Link
US (1) US20220101326A1 (ko)
KR (1) KR102478132B1 (ko)
SG (1) SG11202107662TA (ko)
WO (1) WO2020149790A1 (ko)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11373202B2 (en) * 2018-07-16 2022-06-28 Mastercard International Incorporated Method and system for referral fraud prevention via blockchain
US11601442B2 (en) 2018-08-17 2023-03-07 The Research Foundation For The State University Of New York System and method associated with expedient detection and reconstruction of cyber events in a compact scenario representation using provenance tags and customizable policy
US11257089B2 (en) * 2018-11-28 2022-02-22 Dmg Blockchain Solutions Inc. Cryptographic taint tracking
US11228584B2 (en) * 2018-12-28 2022-01-18 Speedchain, Inc. Systemized blockchain reconciliation in a hybrid distributed network ecosystem
CA3141042A1 (en) * 2019-06-13 2020-12-17 Luis Eduardo Gutierrez-Sheris System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
KR102058683B1 (ko) * 2019-09-05 2019-12-23 (주)에스투더블유랩 암호화폐 거래 분석 방법 및 장치
US11863573B2 (en) 2020-03-06 2024-01-02 ThreatConnect, Inc. Custom triggers for a network security event for cybersecurity threat intelligence
US11379844B2 (en) 2020-06-05 2022-07-05 Elementus Inc. Systems and methods for quantifying and electronically displaying degrees of association between blockchain addresses
KR20230046291A (ko) * 2020-06-10 2023-04-05 시커런시 인크 연맹 권한 및 계층적 키 관리를 위한 방법, 장치 및 컴퓨터 판독 가능 매체
CN112039858A (zh) * 2020-08-14 2020-12-04 深圳市迈科龙电子有限公司 一种区块链服务安全加固系统与方法
US11570198B2 (en) * 2020-09-03 2023-01-31 Bank Of America Corporation Detecting and quantifying vulnerabilities in a network system
US11645666B2 (en) * 2021-01-28 2023-05-09 Show Advertising Ltd. Crowd demographic analysis
US11853278B2 (en) * 2021-06-10 2023-12-26 Jpmorgan Chase Bank , N.A. Systems and methods for combining graph embedding and random forest classification for improving classification of distributed ledger activities
US20220417263A1 (en) * 2021-06-25 2022-12-29 ThreatConnect, Inc. Browser extension for cybersecurity threat intelligence and response
US20230004720A1 (en) * 2021-07-02 2023-01-05 Walter Pelton Logos Communication Platform
KR20230049967A (ko) * 2021-10-07 2023-04-14 한국전자통신연구원 무선 분산 통신 시스템에서 신뢰 필드를 이용한 패킷의 무결성 검사 방법 및 장치
US20230112261A1 (en) * 2021-10-10 2023-04-13 International Business Machines Corporation Validating certificates
US11856004B2 (en) * 2022-03-18 2023-12-26 Capital One Services, Llc Systems and methods for identifying malicious cryptographic addresses
US20230325841A1 (en) * 2022-04-07 2023-10-12 Gen Digital Inc. Systems and methods for detecting websites that perpetrate at least one of scams or frauds
CN114723567B (zh) * 2022-06-10 2022-09-20 深圳市润璟元信息科技有限公司 一种基于区块链技术的金融数据化信息分布式交易系统
US20230412363A1 (en) * 2022-06-17 2023-12-21 Microsoft Technology Licensing, Llc Automated Management of Blockchain Knowledge Repositories
CN115099936B (zh) * 2022-06-27 2023-08-01 长安汽车金融有限公司 一种交易监测系统
CN116663012B (zh) * 2023-05-31 2023-11-03 烟台大学 一种跨合约漏洞的检测方法、系统和设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107085812A (zh) * 2016-12-06 2017-08-22 雷盈企业管理（上海）有限公司 区块链数字资产的反洗钱系统及方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8130700B2 (en) * 2007-06-15 2012-03-06 Silver Spring Networks, Inc. Method and system for providing network and routing protocols for utility services
KR101364763B1 (ko) * 2012-02-20 2014-02-27 주식회사 한국프라임테크놀로지 금융거래패턴분석을 이용한 금융사기 경보 시스템 및 방법
KR101482073B1 (ko) * 2013-05-24 2015-01-14 한국과학기술원 스팸 댓글 차단 시스템 및 방법
US9672499B2 (en) * 2014-04-02 2017-06-06 Modernity Financial Holdings, Ltd. Data analytic and security mechanism for implementing a hot wallet service
US9882918B1 (en) * 2017-05-15 2018-01-30 Forcepoint, LLC User behavior profile in a blockchain

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107085812A (zh) * 2016-12-06 2017-08-22 雷盈企业管理（上海）有限公司 区块链数字资产的反洗钱系统及方法

Also Published As

Publication number Publication date
KR20210014155A (ko) 2021-02-08
SG11202107662TA (en) 2021-08-30
WO2020149790A1 (en) 2020-07-23
US20220101326A1 (en) 2022-03-31

Similar Documents

Publication Publication Date Title
KR102478132B1 (ko) 사이버보안 장치 및 방법
Gupta et al. A novel approach for phishing URLs detection using lexical based machine learning in a real-time environment
US11102244B1 (en) Automated intelligence gathering
US20200311790A1 (en) System, Device, and Method of Protected Electronic Commerce and Electronic Financial Transactions
US11757914B1 (en) Automated responsive message to determine a security risk of a message sender
US11206280B2 (en) Cyber security threat management
Salim Cyber safety: A systems thinking and systems theory approach to managing cyber security risks
Kalla et al. Phishing detection implementation using databricks and artificial Intelligence
Ryan Ransomware Revolution: the rise of a prodigious cyber threat
US11206279B2 (en) Systems and methods for detecting and validating cyber threats
Reedy Interpol review of digital evidence for 2019–2022
Mathew et al. Integration of blockchain and collaborative intrusion detection for secure data transactions in industrial IoT: a survey
Thakral et al. Cybersecurity and ethics for IoT system: a massive analysis
Lessambo Anti-money laundering, counter financing terrorism and cybersecurity in the banking industry: a comparative study within the G-20
Kaur et al. Cybersecurity threats in Fintech
Dunnett et al. Challenges and Opportunities of Blockchain for Cyber Threat Intelligence Sharing
Shahriar et al. Mobile anti-phishing: Approaches and challenges
Chenli et al. Provnet: Networked blockchain for decentralized secure provenance
Kaushik Blockchain enabled artificial intelligence for cybersecurity systems
Seraj Permission-based Android Malware Detection using Machine Learning
Siadati et al. A framework for analysis attackers’ accounts
Aswathy et al. 10 Privacy Breaches
Varshney et al. Anti-phishing: A comprehensive perspective
Gomes de Barros et al. Piracema: a Phishing snapshot database for building dataset features
AlOmar et al. Attention-Based Deep Learning Modelling for Intrusion Detection

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant