문제

iPhone에 암호화된 파일이 있고 이를 해독하고 싶을 때마다 키보드를 사용하여 입력하는 대신 암호 해독 기호를 "그려"고 싶다고 가정해 보겠습니다.

필요할 때마다 파일을 해독하기 위해 기호를 그려달라고 사용자에게 요청하는 경우(예:애플리케이션을 시작할 때마다) 작은 키보드에 20자 정도의 비밀번호를 입력하는 것보다 선호할 것이며 여전히 20자 비밀번호로 제공되는 보안을 얻을 수 있습니다(모양/기호의 복잡성에 따라 다름). 그들이 그리는 것은)입니다.

그들이 그릴 기호는 아마도 한 획일 것입니다(예:손가락을 떼면 끝납니다.) 그러나 매우 복잡할 수 있으므로 다른 사람이 그것을 그리는 것을 보더라도 반복하기 어려울 수 있습니다.모든 사람의 서명이 독특하고 복제하기 어려운 것과 같습니다.실제로 중복을 방지해야 한다면 지나치게 복잡해질 수 있으므로 지금은 무시할 수 있으며 기호가 다른 사람에게 표시되지 않으므로 반복될 수 있는지 여부는 중요하지 않다고 가정할 수 있습니다. 그들에 의해서든 아니든.

진짜 질문은 어떻게 동일한 (합리적으로) 스트로크를 동일한 키로 일관되게 변환할 것인가 하는 것입니다(예:해시 값).사용자가 스트로크를 정확히 100% 반복할 것으로 기대할 수 없기 때문에 알고리즘에는 분명히 어느 정도 관용의 임계값이 있어야 합니다.

기호를 해독 방법으로 사용하면 이 문제에 완전히 다른 차원이 추가됩니다.생성된 해시 값을 암호화되지 않은 형식으로 어디에든 저장하고 싶지 않을 것입니다. 그러면 누군가 하드 드라이브의 해당 부분에 액세스하여 전체 그리기 프로세스를 거치고 파일을 수동으로 해독할 필요 없이 암호 해독 키를 얻을 수 있기 때문입니다.또한 모양이 어떻게 그려지는지에 대한 정보를 저장하고 싶지 않을 수도 있습니다.

사용자가 암호 해독 기호로 사용할 수 있는 스트로크의 좋은 예는 "&" 기호입니다.사용자가 파일의 암호를 해독해야 할 때마다 iPhone에 이 기호를 그리는 것을 상상해 보십시오.기호의 크기는 그릴 때마다 동일하지 않을 수 있습니다.또한, 사용자가 기기를 잡는 방법에 따라 기호의 회전이 달라질 수 있습니다.이상적으로는 두 경우 모두 사용자 스트로크를 기준으로 기호가 동일하게 그려졌기 때문에 동일한 해시 값을 생성하여 파일을 해독할 수 있어야 합니다.

모양이나 문자 인식 같은 것도 비슷한 알고리즘인 줄 알았어요.사용자가 무언가를 그린 다음(합리적으로 모양을 나타냄) 이를 그릴 때마다 동일한 해시 값을 갖는 올바른 모양으로 수정합니다.그러나 이와 같은 경우에는 그릴 수 있는 모양의 데이터베이스가 필요할 가능성이 높으며, 알파벳의 모든 문자와 같은 것을 선택하면 26개의 문자만 얻을 수 있습니다.그리고 사용자가 파일을 해독하기 위해 하나의 기호만 그려야 한다고 가정하면 26가지 가능성만 있는 극도로 안전하지 않은 비밀번호가 됩니다.

제가 생각한 또 다른 점은 작은 세그먼트로 그려진 기호를 분할한 다음 해당 기호 인식을 실행할 수 있다는 것입니다.데이터베이스에 4개의 기호가 있다고 가정해 보겠습니다.수직선, 수평선, 대각선 양방향.이제 사용자가 그림을 그리면 각 세그먼트가 이들 중 하나로 인식되고 모두 결합되어 일부 해시 값을 형성합니다.따라서 사용자가 암호 해독 기호로 소문자 "r"을 선택했다고 상상해 보십시오.그래서 그들은 수직선을 아래로 그리고 수직선을 위로 그리고 대각선을 위로 그리고 오른쪽으로 그리는 것으로 시작했습니다.이 방법의 한 가지 문제점은 스트로크를 개별 세그먼트로 분할할 시기를 어떻게 알 수 있는가입니다.또한 각 개별 세그먼트의 대략적인 길이(예:40픽셀 단위로).이렇게 하면 누군가 바닥 근처에 혹이 나오는 변형된 "r"을 그린 경우 동일한 기호로 인식되지 않으므로 파일의 암호가 해독되지 않습니다.

세 번째 방법은 화면을 그리드로 나누고(아직 크기는 확실하지 않음) 스트로크가 그려지는 셀을 확인하고 이 데이터를 사용하여 어떻게든 문자열을 생성하는 것입니다.

이것이 어떻게 구현될 수 있는지에 대한 다른 아이디어가 있습니까?이런 말을 들어본 적이 있나요?이와 같은 시스템이 작동하지 못하게 하는 근본적인 결함이 있습니까?

감사해요

도움이 되었습니까?

해결책

작은 오류가있을 수있는 Keymaterial을 사용하여 데이터를 암호화하는 문제는 상당히 광범위하게 연구되었습니다. 특히 생체 인식 데이터 (예 : 지문 또는 망막 스캔)를 열쇠로 사용하여 데이터를 보호하기위한 여러 가지 제안이 있습니다. 일반적인 접근 방식은 적절한 오류 수정 코드를 사용하고 원래 키 재료 K를 가져 가서 증후군을 계산하고 증후군 만 저장하는 것입니다. 키 재료 K '를 두 번째로 읽으면 증후군은 K와 K가 충분히 가까운 경우 k에서 k를 복원하는 데 사용할 수 있습니다 (물론'충분히 가까운 곳은 오류 수정 체계에 따라 다릅니다.)

당신을 시작하려면 여기에 제안하는 종이가 있습니다. 퍼지 금고 체계. 이것은 "퍼지"키를 사용하는 암호화 체계에 대한 일반적인 제안입니다. 물론, 이러한 오류 수정 체계를 사용하기에 충분한 도면에서 특성을 추출하는 방법을 검사해야합니다. 또한 그러한 도면에서 얼마나 많은 엔트로피를 추출 할 수 있는지 살펴 봐야합니다. 비밀번호가 엔트로피와 관련하여 나쁘지만 여전히 이길 수 없을 수 있습니다.

다른 팁

나는 분할 변형의 변형을 시도 할 것입니다 : 간단한 패턴을 인식 - 이것을 위해 직선 및 대각선을 고수하지만 이론적으로는 원, 아크 및 기타 것들을 추가 할 수도 있습니다.

8 개의 방향이 있으므로 한 줄이 끝나고 다른 한 줄이 시작될 때 방향 변경을 감지 할 수 있습니다 (또는 더 간단한 접근 방식의 경우 펜을 감지하고 펜을 아래로 내리고 라인 구분 장치로 사용하십시오). 첫 번째 줄은 스케일 팩터를 제공하므로 다른 모든 선의 길이는 계수로 표시 될 수 있습니다 (예 : 일반적인 L 모양으로 첫 번째 수직선은 "기본 길이"B를 제공하고 다른 선은 대략 0.5 * b의 길이). 사용자가 완료되면 가장 작은 요소를 사용하여 길이를 "둥글게"사용하여 [1 * s, 2 * s, 4 * s, 5 * s와 같은 정수 길이를 가질 수 있습니다. 이렇게하면 시스템이 너무 정확하지 않으며 기본 길이를 사용하면 시스템이 스케일링에 대해 강력 해집니다.

이제 어떻게 든 이러한 정보 (길이 및 방향)를 문자열 (또는 원하는 해시 값)으로 변환하면 기호가 번역되거나 스케일링 되더라도 동일한 스트로크에 대해 동일합니다.

또한, 두 번째 줄의 후 모든 라인에 대해 2D 오프셋 값 (물론 "둥근")을 저장할 수 있으므로 라인이 동일한 위치에 있어야합니다. 대부분 동일한 문자열 (1 라인 상승, 1 라인 왼쪽 길이 0.5)을 얻을 가능성이 높습니다. 따라서 포지션을 저장하면 모든 것을 약간 강화하지만 선택 사항입니다.

편집하다:

첫 번째 라인의 각도를 기본 각도로 사용하면 회전에 강력하게 만들 수도 있습니다.

이 알고리즘은 모든 라인이 같은 길이이고 스트로크 당 최대 6-8 비트의 최대 6-8 비트 인 경우 뇌졸중 당 3 비트 만 제공합니다. 이것은 당신이 128 비트의 보안을 얻으려면 약 20-40 스트로크의 매우 복잡한 상징이 필요하다는 것을 의미합니다.

더 많은 변형/보안을 추가하는 쉬운 방법은 사용자가 주어진 팔레트와 다른 색상을 사용하도록하는 것입니다.

누군가가 당신을보고있는 사람의 위험을 줄이기 위해, 당신은 각 선이 그려진 후에 사라지거나 배경과 매우 대비가 매우 낮은 색상으로 색상을 변경할 수 있습니다.

필기 인식은 종종 지속 뇌졸중의 실제 길이와 그 이상의 고려.

압력 감도와 관련이 있지만 여기서 생각하고있는 것과 비슷한 개념적 비트를 볼 수 있다고 생각합니다 .... jdadesign.net/safelock/

그것은 정확히 같은 주제는 아니지만 현재 가장 가까운 곳입니다.

보안 암호화를 수행하기 위해 손으로 그린 ​​기호에서 충분한 "비트"를 얻을 수 없다고 생각합니다.아시다시피 드로잉의 자연스러운 변형이 허용된다는 인식에 충분한 경사를 허용해야 합니다.즉, 스트로크의 노이즈를 제거하여 재생 가능한 신호로 부드럽게 만들어야 합니다.그러나 노이즈(높은 엔트로피)는 더 나은 암호화 키를 만듭니다.

이렇게 생각해보세요.제스처를 위, 아래, 왼쪽, 오른쪽 세그먼트로 분해하면 각 세그먼트는 2비트의 정보를 나타냅니다.AES 키의 경우 기호에는 64개의 세그먼트가 필요합니다.기억하기에는 꽤 복잡한 동작입니다.그리고 연속적으로 많은 세그먼트("오른쪽, 오른쪽, 오른쪽, ...")를 반복하여 단순화하면 형편없는(예측 가능하고 무작위가 아닌) 키가 됩니다.

나는 이것에 대해 또 다른 생각을했다. 나는 comp-sci 사람이 아니지만이 일과 같은 일을 할 것입니다.

누군가가 그리는 상징이나 "패턴"으로 말해 봅시다. 분석해야 할 유일한 실행 가능한 것은 Touchbegan, TouchMoved 및 Touchended 이벤트에서 생성 된 패턴의 모든 점입니다.

그래서 ... 생성 된 모든 점을 100 또는 1,000,000이면 실제로 중요하지 않습니다.

원하는만큼 그룹으로 나눕니다. 내가 생각하는 Merrier가 더 많을수록이 예에서는 4 개의 그룹으로 넣어 봅시다. 100 포인트의 경우 그룹 1은 점 1> 25를 포함하고 그룹 2에는 26> 50 등이 포함됩니다.

각 그룹의 경우 모든 점을 사용하여 평균 위치를 계산하십시오.

캔버스 공간이 그리드로 나누어지고 '평균 위치'가 가장 가까운 좌표로 표시되면 더 잘 작동 할 수 있습니다.

그런 다음 모든 그룹 간의 상대 거리를 확인하십시오. 그래서 1,2 1,3 1,4 2,3 2,4 3,4 사이.

당신은 이제 뚜렷한 포인트와 키를 생성하기 위해 그 포인트에 대한 정보를 많이 가지고 있습니다. 평균과 그리드는 엔트로피가 아닌 경우 일부를 부드럽게하는 데 도움이됩니다.

사용자에게 패턴을 몇 번 그리며 각 그룹과 비교하여 이전 시도의 그룹과 비교해야 할 수도 있습니다. 이렇게하면 사용자가 일관되게 플롯 할 수있는 그룹을 식별 할 수 있습니다. 패턴을 그리는 데 사용자의 손을 훈련시키는 데 추가 이점이 있습니다.

나는 당신이 더 많은 포인트와 그룹을 가질수록 더 정확할 것입니다.

사실, 나는 그것을 스스로 시도 할 것입니다.

제스처.

http://depts.washington.edu/aimgroup/proj/dollar/

특정 제스처에 대한 자신의 알고리즘을 정의 할 수 있습니다. 예 : 원,

1. 시작점을 찾아냅니다. 3. 오류 마진으로 반경에 대한 모든 점을 확인하십시오 (25%?) 4. 반경이 체크 아웃되면 원이 있습니다.

세로 직선 : 1. 시작점과 엔드 포인트 X 및 Y 위치를 점검하십시오. 2. 시작과 끝의 x와 y에 대한 지점을 비교하십시오. 3. 그들이 거의 동일한 X 코디에 있지만 오름차순 또는 내림차순 y coords에 있으면 세로선이 있습니다.

그리고 더 복잡한 제스처를 위해 더 복잡해집니다.

제스처를 결합 할 수도 있습니다. 6 개의 제스처에 대한 알고리즘이 있다고 가정 해 봅시다. 당신은 그것들을 결합하여 다른 기호를 형성 할 수 있습니다. 제스처가 만들어지는 순서가 중요 할 수있어 추가 보안 계층을 추가 할 수 있습니다.

스트로크의 X, Y 좌표를 모두 가져 와서 어떤 종류의 선형 2 웨이 작업을 미리 형성하면 어떻게해야합니까? 그런 다음 '대략적인'해시를 계산할 수 있고 스트로크가있을 때 계산 된 숫자가 근사치의 10%를 말하면 액세스 권한을 부여합니다.

그것은 당신이 방지하려고하는 어떤 종류의 공격에 달려 있습니다. 암호화를 완전히 원한다면 공격자가 암호화 된 파일에 완전히 액세스 할 수 있다고 가정하면 괜찮은 수준의 보호를 달성하려면 많은 엔트로피가 필요합니다. 알고리즘을 올바르게받는다고 가정하면 두 가지를 입력 엔트로피의 힘으로 가져갈 수 있습니다 (이에 대한 상한은 가능한 다른 입력의 수입니다), 주요 설정 절차의 시간을 곱합니다. 공격자가 보유한 컴퓨팅 성능의 양으로 나누고 공격자가 무차별으로 암호화를 깨기 위해 걸리는 시간을 얻습니다.

예를 들어, 9 Cell Figure Unlock의 Android 방법과 같은 것은 약 16 비트의 엔트로피를 얻을 수 있습니다. 암호화 키를 계산하기 위해 5 초의 CPU 시간을 사용한다고 가정하겠습니다. 그런 다음 평균 PC의 경우 5*2 ** 16/20 초 또는 약 4.5 시간이 걸립니다. 키 세트 및 암호화의 입력 또는 비 효율성에서 엔트로피의 손실은 컴퓨터 클러스터가 사용되는지는 말할 것도없이 몇 분으로 빠르게이를 줄입니다.

솔직히 말해서 파일을 모호한 파일 형식으로 저장하고 아무도 그것을 알아 내지 않기를 바라는 것보다 훨씬 낫지는 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top