쎄이 시큐리티 - Say Security

생체인증에 관한 이야기 시작....

최근 기사만 봐도 알 수 있듯이 최근 금융권에서는 FIDO도 뿐만 아니라, 손바닥 정맥이나 홍채인식을 통한 ATM 무인점포 등 생체인식 시스템을 경쟁적으로 도입하는 것을 알 수 있습니다.

관련기사, <직원·점포 없이 거래 맘대로...은행들 바이오인증 도입 붐>

FIDO는 애플페이, 삼성페이 등 생체인식을 활용한 모바일간편결제 및 인증 상용화에 따라 많은 주목을 받고 있고 이에 대해 제가 간단하게 포스팅도 했었습니다.

<핀테크 보안 핫 이슈, 생체인증을 주도할 FIDO 이야기>

위 글에서도 언급했지만, FIDO를 이용한 생체인증의 핵심은 공개키기반로서 실제 서비스를 제공하는 서버에 절대 사용자의 생체정보가 저장되지 않고 공개키만 저장된다고 설명했었습니다(생체인증은 사용자 단말에서의 개인키에 접근하기 위한 로컬인증에 사용할 뿐).

오늘은 같은 생체인증 이야기이지만, 생체정보관리 측면에서 FIDO와는 다르게 사용자의 생체정보를 서버에 저장하여 생체인증을 서비스하는 생체인식 시스템에 대해서 간략하게 설명하고자 합니다. 은행에서 도입하는 생체인식을 활용한 ATM 서비스 등은 홍채/정맥/지문 등 사용자의 생체정보를 은행들이 직접 수집/저장/관리하며, 사용자가 인증 시도 시 등록된 생체정보와 비교함으로써 본인여부를 판단합니다. 이러한 생체인식 시스템에 대해 개념적 구조설명과 기업 입장에서 사용자 생체정보의 보안요구사항에 대해 간략하게 이야기 하겠습니다.

생체인식에 사용할 생체정보의 특성

생체인증은 본인을 증명하는 수단으로써 기존의 패스워드가 아닌 사용자가 보유한 생체정보를 이용하기 때문에 생체인식 시스템에서 사용할 생체정보는 다음의 특성이 요구됩니다.

• 보편성(Universal) : 누구나 갖고 있는 특성
• 유일성(Unique) : 각 개인을 구별할 수 있는 고유한 특성
• 영속성(Permanent) : 변하지 않고 변경이 불가한 특성
• 획득성(Collectable) : 센서에 의한 획득과 정량화가 용이한 특성

이러한 요구특성을 고려하여 홍채, 지문, 정맥, 음성 등 다양한 생체정보를 활용하게 됩니다.

예를 들어, 후지쯔사에서는 손바닥의 정맥을 이용하여 생체정보를 추출합니다.

생체인식 시스템 구조

[용어정의]

• 생체인식 특성(Biometric Characteristics) : 생체인식 특징을 추출할 수 있는 개인의 생리학적 특성이나 행동 특성

• 생체인식 샘플(Biometric Sample) : 생체인식 획득 서브시스템으로부터 얻은 생체인식 특성의 아날로그 또는 디지털 표현

• 생체인식 레퍼런스(Biometric Reference) : 하나 이상의 저장된 생체인식 샘플, 생체인식 템플릿 또는 생체인식 모델

• 생체인식 특징(Biometric Feature) : 생체인식 샘플에서 추출된 것으로 비교에 사용되는 데이터(숫자 또는 레이블)

생체인식 시스템의 구조는 아래 그림과 같습니다.

<그림> 생체인식 시스템 구조

DATA Capture Subsystem(데이터 획득 서브시스템)

이 서브시스템은 센서를 통해 사용자의 생체인식 특성을 입력받아 생체인식 특징을 추출하기 위한 생체인식 샘플을 생성합니다. 예를 들어, 지문인식의 경우 지문이미지, 음성인식인 경우 음성 녹음파일 등을 추출합니다. 생체인식 샘플은 같은 사용자가 사용할 때마다 매번 다른 샘플이 추출될 수 밖에 없습니다. 그 이유는 센서를 통한 인식 시 조명, 온도 등 주변 환경 및 사용자의 사용패턴에 따라 매 번 다를 수 밖에 없기 때문입니다.

Signal Processing Subsystem(신호처리 서브시스템)

이 서브시스템은 생체인식 샘플을 입력받아 다른 샘플과 유사도를 비교할 수 있는 생체인식 특징을 추출합니다. 생체인식 특징을 추출하는 알고리즘은 제조사 고유의 기술로서 이에 따라 얼마나 효율적으로 정확하게 비교할 수 있는지가 결정됩니다. 참고로, 사용자가 처음 생체정보를 등록할 경우, 이 서브시스템에서 추출된 생체인식 특징은 데이터 저장 서브시스템에 생체인식 레퍼런스로 저장됩니다. 등록 이후 사용자 인증을 시도할 경우 생체인식 특징은 저장된 생체인식 레피런스와 비교하기 위해 비교 서브시스템으로 전달될 것입니다.

Data Storage Subsystem(데이터 저장 서브시스템)

이 서브시스템은 사용자의 등록된 생체인식 레퍼런스를 저장하는 데이터베이스입니다. 주로 사용자의 신원정보와 함께 연계할 수 있도록 구성됩니다. 하지만 생체인식 레퍼런스 데이터베이스는 개인정보 보호를 위해 신원정보와 직접적으로 연결하지 않고 논리적/물리적으로 분리운영해야 합니다. 예를 들어, 생체인식 레퍼런스 데이터베이스가 해킹당하더라도 누구의 생체정보인지 바로 알 수 없도록 보호해야 합니다.

Comparison Subsystem(비교 서브시스템)

이 서브시스템은 사용자로부터 획득된 생체인식 특징을 저장된 생체인식 레퍼런스와 비교하여 유사도를 측정합니다. 비교대상의 일치여부를 판별하지 않고 유사도(특징이 얼마나 유사한가)를 측정하는 이유는 앞서 설명한 바와 같이 같은 사용자가 같은 센서를 사용하여 생체인식 샘플을 추출하더라도 절대 환경적 요인으로 같을 수는 없다는 사실에 기반하여 일치할 수는 없는 것입니다. 하지만 같은 사용자이기 때문에 거의 유사한 특징이 추출되겠죠. 다시 말해, 인증 시도 시 유사하기는 하나 일치할 가능성이 거의 없으며 오히려 완전히 일치하는 경우 재사용 공격으로 판단하는 것이 옳을 것입니다.

그리고 비교 서브시스템에는 1:1 비교하는 경우와 1:N으로 비교하는 경우가 있습니다. 만약 주민등록번호 같은 신원정보와 함께 생체인증을 시도하는 경우 해당 신원정보에 해당하는 저장 정보와 1:1 비교를 하겠지만 아무 정보 없이 생체인증을 시도할 경우 1:N으로 비교해서 해당 사용자가 존재하는지 부터 판단하게 되겠죠.

Decision Subsystem(판정 서브시스템)

이 서브시스템은 비교 서브시스템으로부터 유사도(점수)를 입력받아 인증 성공 또는 실패를 결정합니다. 임계치를 설정하여 유사도가 임계치를 넘으면 성공이고 그 보다 낮으면 실패로 판정하는 개념입니다. 임계치를 설정하는 것이 매우 중요하겠죠.

생체인식 정확도 측정 기준

생체인식을 사용할 경우 위의 각 서브시스템 특성에 따라 정확도가 높을 수도 있고 낮을 수도 있습니다. 정확도가 높을 수록 신뢰할 수 있고 비용도 비싸겠죠. 생체인식 시스템의 정확도를 측정하는 기준은 아래와 같습니다.

  1) 본인거부율(FRR: False Rejection Rate)

   - 허가된 사용자(본인)가 시스템의 오류로 인하여 접근 거부되는 비율

  2) 타인허용율(FAR: False Acceptance Rate)

   - 허가되지 않은 사용자(타인)가 시스템의 오류로 인하여 접근 허용되는 비율

  3) FRR/FAR 교차점(CER : Crossover Error Rate)

   - 본인거부율(FRR)과 타인허용율(FAR)의 교차점

   - EER : Equal Error Rate

  4) 등록실패율(FER : Failure to Enroll Rate)

   - 하나의 생체 원시 데이터 레코드를 등록할 수 없는 사용자가 발생할 비율

• 시스템의 정책과 중요도에 따라 생체인식 시스템에 요구되는 FAR과 FRR의 값이 달라짐

• 엄격한 보안이 요구되는 경우는 FAR을 낮추고 FRR을 증가시킴으로써 보안성을 향상시킬 수 있음

생체인증의 키인 생체정보에 대한 보안요구사항

기밀성(Confidentiality)

저장된 생체인식 레퍼런스는 개인의 중대한 프라이버시에 해당하기 때문에 기밀성이 확보되어야 합니다. 검증 및 식별을 위해 신원정보와 결합되거나 비교 서브시스템으로 전송 시 접근 통제 및 다양한 암호화 기법을 적용해야 합니다.

무결성(Integrity)

생체인증의 신뢰도를 위해서는 생체인식 레퍼런스가 악의적 공격에 의해 위변조되거나 시스템의 오동작에 의해 무결성이 훼손되지 않아야 합니다. 

재발급성 및 폐기성(Renewability and revocability)

앞의 기밀성과 무결성은 보안의 3요소에도 있듯 당연하게 생각되겠지만 이 부분은 조금 생소할 수 있습니다. 만약 아이디/패스워드가 유출된 경우 어떻게 대응합니까? 사실을 알리고 패스워드를 급히 변경하게 하죠. 생체인식도 마찬가지 입니다. 생체인식 레퍼런스 데이터베이스가 해킹되거나 훼손된 경우 대응방안으로 해당 레퍼런스는 즉시 폐기하고 재발급해야야 할 것입니다. 앞에서 사용자의 생체인식 특성으로부터 샘플 및 특징을 추출하는 것은 생체인식 시스템의 중요한 기술이라고 했습니다. 재발급은 사용자의 생체정보가 노후화되어 인증성공률이 낮아져 갱신하기 위해 재발급하는 일반적인 경우도 있겠지만, 해킹에 의해 유출되어 재발급해야 한다고 생각해봅시다. 사용자의 생체정보가 변했을리 없는데(영속성: 변해서도 안되고) 같은 센서, 같은 특징추출 알고리즘을 적용할 경우 재발급한 레퍼런스는 유출된 기존 레퍼런스와 유사하게 생성될 수 밖에 없습니다. 이는 유출된 레퍼런스를 폐기하고 재발급했다고 보기 어려울 것입니다(유출된 패스워드를 새로운 패스워드로 변경하는 것과 같은 이치). 같은 생체정보로부터 다른 레퍼런스를 생성할 수 있어야 가능하겠죠. 

생체인식 시스템 도입 시 보안 담당자로서의 체크 포인트

생체인식 시스템을 도입할 경우 다음을 고려해야 할 것입니다.

신뢰도

앞서 설명한 생체인식 정확도 측정기준을 활용하여 신뢰도를 고려해야 합니다. 특히, 보안측면에서는 타인수용률인 FAR이 매우 중요합니다.

생체인식 시스템의 보안 요구사항

생체인식 레퍼런스의 기밀성, 무결성, 재발급성 및 폐기성이 확보되는지를 고려해야 합니다. 최근 생체인식 시스템의 경우 기밀성과 무결성은 어느 정도 만족하지만 재발급성 및 폐기성을 제공하는 업체는 많지 않은 것 같습니다. 현재는 금융권에 생체인식 시스템이 활성화되는 시작단계라서 사용자의 생체정보가 수집된 경우가 극히 적지만, 앞으로 생체인식 시스템이 더욱 활성화 된다면 수집 및 저장되는 경우가 많아지고 관련 사고발생 시 그 대응방안으로 재발급성 및 폐기성이 핵심화두로 떠오르지 않을까 개인적으로 생각합니다.

생체정보 프라이버시

생체정보는 매우 민간함 개인정보로서 다음을 고려해야 합니다.

• 비가역성(Irreversibility) : 사용자로부터 추출한 생체인식 데이터는 비가역적으로 처리되어 생체인식 데이터로부터 사용자정보를 알 수 없어야 함
• 불연계성(Unlinkability) : 저장된 생체인식 레퍼런스는 애플리케이션 또는 데이터베이스 간에 연계 불가해야함
• 기밀성(Confidentiality) : 생체인식 레퍼런스에 접근하는 것을 방지하기 위해 생체인식 레퍼런스는 기밀성을 유지해야 함

위와 같은 목표와 함께 생체인식 정보 라이프싸이클(수집/저장/사용/폐기)에 따른 프라이버시 보호 대책을 수립해야 합니다.

단계별 위협 대책

생체인식 시스템의 각 단계별 위협에 대한 보안대책을 고려해야합니다.

• 데이터획득/신호처리 단계 : 생체인식 샘플이나 특징에 대해 도청/재사용/무작위대입
• 저장/비교 단계 : 생체인식 레퍼런스에 대해 도청/재사용/힐클라이밍
• 판정 단계 : 유사도 점수 및 임계치 조작

기타

• CC인증 등 신뢰있는 기관으로부터의 인증 확인
• 사업 특성을 고려하여 적절한 생체인증 유형 검토
• 이중화, 아카이빙 및 백업 등 가용성 확보 대책 등

더 자세한 내용은 생체인식 시스템 관련 표준을 참고하면 되겠습니다.

ISO/IEC 24724 Biometric Templete Protection

X9.84 Biometric Information Management and Security for the Financial Services Industry

한국정보보호진흥원, 생체정보 보호 가이드라인 (2005) 등

<추가>

관련 기사 참조하시면 좋겠네요.

<금융권 흔드는 생체인증, 얼마나 안전할까?>

위 기사에서 얘기하는 보안 대책 중,

- 전체지문정보를 저장하지 말라는 것은 비가역성과 연관이 있고

- 템플릿을 비밀번호 변경하듯 변경할 수 있어야 한다는 것은 재발급성 및 폐기성과 관련이 있습니다.

- 마지막으로, 템플릿을 분산저장하는 것은 그 방식자체가 템플릿 유출 가능성을 낮출 수는 있으나 완전히 제거할 수 있는 것은 아니기 때문에 재발급성과는 별개로 대책수립이 되어져야 할 것입니다.

[참조]

X9.84-2003 Biometric Information Management and Security for the Financial Services Industry

ISO/IEC 24745 Biometric Templete Protection

http://www.christoph-busch.de/files/Busch-EAB-ISO-24745-120713.pdf

최근 핀테크...핀테크..하면서 정부정책부터 기업에 이르기까지 핀테크로 먹거리를 찾기위해 분주하죠. 우리나라에서는 소위 '천송이코트' 이슈로 인해 불거졌다고 할 수 있는데요. 핀테크분야도 광범위하지만 그 중에서도 우리나라에는 간편결제분야에 많이 집중하고 있죠. 핀테크에 대해서는 나중에 따로 정리한번 하도록 하고 간편결제 또는 간편송금 등에 활용할 간편인증 방식으로 각광받고 있는 FIDO에 대해서 이야기 하고자 합니다.

FIDO 등장배경

FIDO는 Fast IDentity Online의 약자로서, 온라인 환경에서 빠르게 인증을 수행하기 위한 기술표준입니다. 지금도 온라인상에서 많은 사이트에 가입하고 로그인 하면서 쓰고 있는데 왜 굳이 FIDO라고 해서 새롭게 등장하는 것일까요? 우리는 기억도 못할 정도로 다양한 곳에 아이디와 패스워드를 만들고 가입하여 사용하고 있습니다. 항상 패스워드에는 보안을 강화하라고 하고 있지만 너무 많은 곳에 패스워드를 등록하여 사용하는 우리는 그것들을 다 기억하기 어렵죠. 그래서 대부분 동일한 아이디와 패스워드를 사용함에 따라 한 번 패스워드가 유출되면 그 파급 효과는 엄청나겠죠.

이렇듯 패스워드 의존도는 낮추면서 개방성˙확장성˙상호운용성을 제공하는 인증방식 개발을 목표로 2012년 7월 비영리단체인 FIDO Alliance가 설립되었고 2014년 12월 9일 FIDO 1.0을 공개했습니다. 조만간 2.0이 나올 것으로 알고 있구요.

FIDO의 2가지 표준

FIDO Alliance에서는 2가지의 표준을 공개했습니다. 두 표준 모두 공개키방식이며, 둘 중 원하는 것을 선택해서 활용하면 됩니다.

첫 째는 UAF(Universal Authentication Framework)표준으로 비패스워드(Passwordless)방식으로 지문, 음성, 홍체, 얼굴 등 사용자 고유의 생체정보 인증방식입니다. 디바이스에서 생체인증을 성공하면 디바이스에 저장된 개인키에 접근권한이 발생하여 전자서명하는 방식입니다.

둘 째는 U2F(Universal 2nd Factor)표준으로 기존 패스워드방식을 1차 인증요소로 사용하고 보안키를 저장한 동글을 이용하여 2차인증을 추가하는 인증방식입니다. USB로 연결된 동글내 버튼을 누르거나 NFC를 이용하여 탭핑하는 방식 등이 사용 시나리오로 등장합니다.

FIDO 사용 사용시나리오

생체인증을 활용하는 UAF를 예를 들어 FIDO를 어떻게 사용하는지 알아보겠습니다.

크게 ①등록, ②로그인 하는 시나리오에 대해서 설명하겠습니다.

등록

site.com에서 FIDO인증을 사용하기 위해 ①등록버튼을 누르고 ②지문인증을 하면 ③디바이스의 안전한 공간에 개인키/공개키 쌍을 새로 생성하여 ④site.com에 공개키를 전송하여 등록하게 됩니다. 이 때, 새로은 키는 디바이스별/서비스별/사용자계정별로 고유하게 생성됩니다.

로그인

등록된 site.com 사이트에 FIDO를 이용하여 쉽게 로그인하는 과정입니다. ①site.com에 로그인버튼을 누르고 ②지문인증을 하면 ③사이트에 등록된 공개키 쌍에 해당하는 개인키에 접근이 가능하고(실제 첼린지방식의 전자서명 수행) ④서버는 전자서명 확인 후 서비스에 로그인이 됩니다.

중요) FIDO를 생체인증이라고 생각하지만 생체인증은 디바이스 단에 저장된 개인키에 접근하기 위한 편리하고 안전한 인증수단을 제공할 뿐(디바이스 로컬인증) 실제 서버와의 인증 자체는 공개키방식이라고 생각하면 됩니다.

FIDO 주요 구성

UAF에 대한 구성을 살표보겠습니다.

UAF 프로토콜

사용자 단말과 서비스간의 프로토콜로서 앞에서 설명한 등록 및 사용자 인증(로그인)을 위한 프로토콜 외에 등록을 해제하는 등록해제, 그리고 보안 트랜잭션 확인(ex: 거래내용 확인) 프로토콜을 제공한다.

UAF 클라이언트/서버

UAF 프로토콜 통신을 위한 클라이언트 및 서버에 해당합니다. 클라이언트는 디바이스내 위치하고 서버는 서비스에 위치하여 등록된 사용자 계정에 대한 UAF 인증자 관리 등의 역할을 수행합니다.

UAF 인증자(Authenticators)

인증자는 보안 엔티티(Secure Entity)에 인증키를 생성하고 인증을 위한 서명을 수행합니다. 그림에서도 알 수 있듯이 인증자는 하나의 디바이스에 여러개가 존재할 수 있는데 지문, 홍체, 음성 등 생체인증 유형 별 제조사에 따라 존재하게 됩니다. 예를 들어, 삼성갤럭시 휴대폰의 지문인증도 하나의 인증자를 제공하고 임의의 기업이 삼성지문인증을 활용하여 다양한 서비스를 만들기 위해 FIDO 클라이언트를 구현하여 활용할 수 있는 구조입니다.

FIDO 프로토콜 동작 방식

앞에서 등록과 인증시나리오에 대해서 살펴보았으나 이번에는 FIDO에서 제공하는 4가지 프로토콜에 대한 플로우를 간단히 알아보겠습니다.

인증자 등록(Authenticator Registration)

①등록을 시작하면 ②서버에서 인증자에 대한 정책을 보내줍니다.

③사용자는 사용할 인증자를 선택하여 로컬인증을 수행하면 고유한 개인키/공개키 쌍을 생성하여 개인키는 안전한 보안엔티티에 저장하고 ④공개키는 서버로 전송한다. 이 때 Attestation(Authenticator Attestation ID, 인증자의 밴더 및 모델에 따라 제조시 저장한 고유한 키)를 함께 전송하면 ⑤서버에는 응답을 확인하고 Attestation과 공개키를 저장한다.

인증(Authentication)

①인증을 시도하면 ②서버에서 인증자에 대한 정책과 함께 첼린지값을 보내줍니다.

③사용자는 로컬인증을 수행하면 해당 개인키를 사용하여 첼린지 값에 전자서명을 하고 ④서버로 전송합니다. ⑤서버는 서명된 첼리지값을 사용자의 공개키로 검증함으로써 인증을 완료합니다.

트랜잭션 확인(Transaction Confirmation)

트랜잭션 확인의 활용을 예를 들면, 금융거래 후 거래할 내역이 맞는지 확인할 때 사용할 수 있습니다. 거래내용을 클라이언트에 전송하고 거래내용에 개인키로 서명하게 함으로써 중요거래에 대해 사용자에게 확실하게 인증받는 것입니다. 거래내용 무결성에 해당하고, 이를 잘 활용하면 부인방지에도 활용할 수 있겠죠.

①거래확인을 시도하면 ②서버에서는 트랜잭션 텍스트를 보내줍니다. 거래내용 등이 들어갈 수 있겠죠.

③사용자는 수신된 트랜잭션 텍스트를 확인하고 로컬인증을 수행하면 확인한 트랜잭션 텍스트에 대해 해당 개인키를 사용하여 전자서명을 하고(해시를 이용할 수도 있겠죠) ④서버로 전송합니다. ⑤서버는 트랜잭션 텍스트 서명값을 사용자의 공개키로 검증함으로써 트랜젝션 텍스트에 대한 무결성을 보증할 수 있습니디ㅏ.

인증자 해제(Authenticator Deregistration)

서비스를 더 이상 사용하지 않을 경우 해제를 할 수 있습니다.

①서버에 접속 후 해제를 신청하면 ②서버로부터 등록해제메시지를 수신하면 ③인증자에서 관련 정보를 삭제합니다. 물론 서버에서도 삭제를 하겠죠.

금융거래 활용 시 보안 담당자로서의 체크포인트

지금까지 FIDO 개념으로 시작해서 프로토콜까지 살펴보았습니다. 요약하면 FIDO는 온라인 환경에서 편리하고 안전하게 인증을 하기 위한 기술표준이며 주로 생체인증에 많이 사용될 수 있습니다. FIDO는 생체인증을 지원하지만 실질적으로는 공개키방식이라는 점을 인지하셔야 하며, 개인키에 접근하기 위해 다양한 인증을 제공할 수 있고 다양한 인증을 제공하기 위해서는 인증자가 제조사로부터 공급되어야 합니다. 또한 FIDO 생체인증을 활용할 경우 클라이언트 단말에서나 생체정보가 활용되는 것이지 서버에는 절대 사용자 생체정보가 저장되는 것이 아닙니다(공개키가 저장될 뿐). 

다양한 인증방식이 생길 수록 다양한 제조사가 생긴다는 얘기인데요, 결국은 개인키관리가 보안의 핵심인데 이를 관리하는 인증자를 얼마나 안전하게 만들었냐가 중요합니다. 따라서 생체인증을 이용하여 FIDO를 도입할 경우 개인키관리를 얼마나 잘하는지가 중요하겠습니다. 

그리고, FIDO를 이용하여 최근 단순인증기능에 사용하기도 하고 금융거래에서 공인인증서를 대체하여 사용하려고 하기도 합니다. FIDO를 어디에 활용하느냐에 따라 그 중요도가 달라지는데요, 만약 금융거래 중 계좌이체에 활용한다고 가정하면 높은 보안강도를 필요하겠죠. 게다가 우리나라에서는 아직도 부인방지에 대해 많이 고민하는 것 같습니다. 만약 FIDO를 이용하여 거래사실에 대한 부인방지까지 고려하고 싶다면 결국 TTP(Trusted Third Party)에서 공개키를 인증할 수 있는 기반구조를 구축하는 것이 가장 확실하겠죠. 그런데 이런 모양으로 가다보면 결국 공인인증서의 또 다른 형태가 될 것 같습니다.

마지막으로, FIDO 도입 시 FIDO Alliance 에서 인증여부를 확인 할 수 있습니다.

(https://fidoalliance.org/certification/fido-certified)

Client/Server/Authenticator 로 구분하여 각 제조사별로 인증여부에 대한 정보가 공개되어 있으니 도입 시 확인하시면 도움될 것 같습니다.

[참고]

https://fidoalliance.org/specifications/overview

UAF Technical Overview, Davit Baghdasaryan, Nok Nok Labs