업데이트 PIPELINE이 녹색이고, 에지에서 패키지가 사용 가능하고, 장치가 이를 확인하고 있는 상황입니다. 그런 다음 누군가가 생성된 자바스크립트에서 의심스러운 변경 사항을 발견합니다. 빌드 러너가 위협을 받은 것일 수 있고, 개발자 인증 정보가 도난 당했을 수 있고, 전달 계층에서 변경된 아티팩트가 있을 수 있습니다. 테스트가 끝난 후에도 배포에 위협이 포함될 수 있습니다. 서명 확인이 없다면, 클라이언트는 팀이 빌드한 패키지와 공격자가 전송 중이나 전달 계층에서 변경한 패키지를 구분할 수 없습니다., the client has no reliable way to distinguish the bundle your team built from one an attacker modified in transit or at the delivery layer.
Signed updates change that decision. The device verifies the bundle against a trusted public key before it replaces the currently running code. If the signature doesn’t match, the update stays inactive. That sounds straightforward, but production failures usually happen around the cryptography, not inside it. Teams lose track of key rotation, sign the wrong artifact, apply an unverified cached file, or collect so little telemetry that they can’t explain which devices rejected an update.
목차
서명 확인이 재난을 예방하는 이유
- 암호학적 서명이 신뢰를 창출하는 방법
- 모바일 전달을 위한 알고리즘 선택
- Table of Contents
- 완전한 인증 흐름 구축
- 대부분의 팀이 저평가하는 키 관리의 어려움
- CI/CD 및 모니터링에 인증 통합
- 보안 최적화 방법 및 일반적인 함정
서명 인증이 재난적인 업데이트를 방지하는 이유
popular한 Capacitor 플러그인 CI/CD pipeline이 릴리스 프로세스의 마지막 단계에서 해킹된다. 공격자는 live update 패키지를 수정하고 code를 추가하여 애플리케이션 데이터를 읽고, 그리고 일반적인 배포 경로를 통해 pipeline의 배포 경로를 사용하여 아티팩트를 게시한다. 장치에서는 불알인 다운로드 도메인을 보지 못한다. 그들은 설치 대기 중인 유효한 업데이트를 보게된다.
클라이언트 측 암호화 확인이 없으면 앱은 업데이트 정책이 허용하는 즉시 수정된 패키지를 다운로드하고 실행할 수 있다. 데이터 유출, 자격 증명 도난, 지불 흐름 변경, 비밀스러운 비즈니스 논리 조작이 포함된 폭발적인 범위가 가능하다. 조사도 고통스럽다. 엔지니어들은 어떤 아티팩트가 제공되었는지, 어떤 채널이 그것을 받았는지, 어떤 장치가 그것을 다운로드했는지, 어떤 장치가 그것을 적용했는지, 그리고 해킹된 code가 릴리스가 취소되기 전에 실행되었는지 결정해야한다.
code
생성자 인증이 활성화된 팀은 다른 실패 모드를 얻습니다. 앱은 동일한 오염된 패키지를 다운로드하고 예상한 해시를 계산한 다음 신뢰할 수 있는 키와 첨부된 서명과 비교합니다. 암호화된 검사 실패, 업데이터가 패키지를 활성화하지 않으며 새로운 __CAPGO_KEEP_0__이 실행되기 전에 보안 팀에 이벤트가 도달합니다. 생산 규칙:
The protection only works if the verifier runs on the device, before extraction or activation, and if the trusted key can’t be replaced by the update itself. That makes certificate and key handling part of the update design, not an administrative detail. Teams using Capacitor should document this boundary alongside their 보호가 작동하려면 검증기가 장치에서 실행되어 추출 또는 활성화 전에 실행되어야 하며 신뢰할 수 있는 키가 업데이트로 대체되지 않아야 합니다. 따라서 인증서 및 키 관리는 업데이트 디자인의 일부가 아닌 관리 세부 사항이 됩니다. __CAPGO_KEEP_0__을 사용하는 팀은 인증서 관리 프로세스와 함께 이 경계를 문서화해야 합니다.인증서 관리 프로세스
인증서 관리 프로세스 0.5% 거짓 인정을 7% 거짓 거부거짓 수락 거짓 거부서명 인증 연구의 역사적 개요 __CAPGO_KEEP_0__이러한 통계는 소프트웨어 업데이트와 관련이 없지만, 검증의 품질은 검증자, 참조 데이터 및 결정 정책에 따라 달라진다는 점을 강조한다.
암호학적 서명이 신뢰를 창출하는 방법
릴리즈 버ंडल을 생각하면封지에 서명이 달린 편지와 비슷하다. 빌드 시스템은 정확한 바이트의 해시를 계산하고, 개인 키 해시를 사용하여 해시를 생성한다. 앱은, 또는 안전하게 받은, 해당 공개 키가 있다. 이 공개 키는 편지에 있는 알려진 문장과 비슷하다. 공격자가 버ंडल의 작은 부분을 변경하면, 앱은 다른 해시를 계산하고 서명이 더 이상 유효하지 않게 된다.
이 흐름은 네 가지 구별된 부분으로 구성된다.
- 해싱 버ंडल을 고정 길이의 해시로 변환한다. SHA-256 및 SHA-512은 이 무결성 단계에서 일반적으로 사용되는 해시 알고리즘이다.
- 키 생성 비대칭 pair를 생성합니다. 개인 키는 서명하고, 공개 키는 인증합니다.
- 서명 해시를 릴리스 메타데이터와 결합합니다. 버전, 채널, 플랫폼, 그리고 대상자를 포함하는 것이 좋습니다.
- 인증 다운로드한 바이트에서 해시를 재계산하고, 신뢰할 수 있는 개인 키가 서명한 것을 확인합니다.
인증자는 업데이터가 적용할 동일한 페이로드와 서명을 결합해야 합니다. 매니페스트에 대한 서명만으로는 앱이 나중에 다운로드한 배ंडल의 해시가 매니페스트의 해시와 일치하는지 확인하지 않으면 충분하지 않습니다. 또한 배ंडल의 해시를 확인하는 것은 인증자가 누구인지establish하지 않습니다. 해시 자체가 인증되야 합니다.
모바일 배포를 위한 알고리즘 선택
RSA는 친숙하고 널리 지원되지만 보통 더 큰 키 자료와 주의 깊은 패딩 선택이 필요합니다. 새로운 모바일 업데이트 프로토콜에서 Ed25519는 종종 매력적이기 때문에 키와 서명이 compact하고 모바일 프로세서에서 인증 경로가 효율적입니다. RSA-PSS도 호환성 요구 사항이 RSA가 필요하도록 만드는 경우 적절할 수 있습니다. 선택은 플랫폼 암호 라이브러리, 지원되는 하드웨어, 상호 운용성 요구 사항, 그리고 마이그레이션 계획에 따라야 합니다. 다른 환경에서 복사한 벤치마크에 따라서는 아닙니다.
이 안내서를 참조하세요. 블록체인에 대한 암호학적 서명 이해을 통해 독립적인 소개가 있습니다. 거래 컨텍스트는 OTA 배포와 다르지만, 개인 키 인증과 공개 키 인증에 대한 설명은 직접 전달됩니다.
신뢰 체인과 고정 키
A 인증 체인은 루트에서 중간 인증 기관을 통해叶 인증서에 신뢰를 위임합니다. 이 모델은 광범위한 PKI 작업을 단순화할 수 있지만 앱 업데이트한 클라이언트는 일반적으로 좁은 요구 사항을 갖습니다: 이 업데이트를 승인 한 출판자의 키만 신뢰하십시오. 공개 키 또는 승인된 키의 작은 집합을 앱 바이너리에 직접埋め込는 것은 고정 키의 한 형태입니다. 이 방법은 외부 인증 기관에 대한 의존성을 줄이지만 바이너리가 이미 새로운 키를 신뢰해야 하는 문제를 만듭니다.
서명된 편지 전체를 유지하십시오. 릴리스 메타데이터는 아티팩트, 해시, 목표 채널, 및 키 식별자를 식별해야 합니다. 이 기능을 구축하는 팀은 Capacitor를 사용하여 Capacitor 앱을 위한 고유한 Capacitor 앱의 토큰 서명 체크리스트 모바일 및 웹 시스템에서 실제 응용 사례
실제 세계 모바일 및 웹 시스템에서 사용하는 방법
API
layer를 혼동하면 결함이 생깁니다. 유효한 IPA 서명은 자동으로 후속 웹 패키지를 인증하지 않습니다. 유효한 JWT는 업데이트 패키지가 안전하다는 것을 증명하지 않습니다. TLS 연결은 수송을 보호하지만, CDN, 프록시, 캐시 또는 빌드 시스템이 도난을 일으킬 때 서명된 아티팩트를 대체하지 않습니다.
| 상황 | 서명 메커니즘 | 실패 모드 방지 | 일반적인 결함 |
|---|---|---|---|
| 앱 스토어 패키지 | 플랫폼 code-서명 및 플랫폼 검토 제어 | 재 서명되거나 권한이 없는 설치 가능한 패키지 | 팀은 스토어 서명이 설치 후 웹 자산을 커버한다고 가정합니다. |
| 웹 패키지 및 서비스 워커 | 서명된 교환 또는 SRI-style完整성 참조 | 중독된 CDN 응답 또는 수정된 자산 | 만들어진 파일만 검사하고, 불러온 자산은 검증되지 않습니다. |
| API 토큰 | JWT 서명은 신뢰할 수 있는 공개 키를 통해 유효화되며, 종종 JWKS 엔드포인트를 통해 얻습니다. | 위조 또는 변조된 토큰 | 서버는 서명이 유효하지만, 발급자, 수신자, 만료일, 또는 토큰 목적을 무시합니다. |
| OTA 업데이트 | 디바이스에서 분리된 또는 내장된 번들 서명이 검증됩니다. | 인터넷 공격자 또는 변조된 업데이트가 주입됩니다. | 클라이언트는 콘텐츠를 다운로드, 캐시, 또는 압축하기 전에 결정을 강제합니다. |
웹 자산의 경우, 서브 리소스完整성은 브라우저가 참조한 리소스에 대해 받아들일 수 있는 것을 제한할 수 있지만, 동적 임포트, 서비스 워커 캐시, 또는 업데이트한 매니페스트가 공격자 선택한 파일을 참조하는 경우 자동으로 해결되지 않습니다. 구현은 완전한 아티팩트 집합을 정의하고, 실행할 bytes를 검증해야 합니다.
JWT 배포는 다른 방식으로 실패합니다. 개발자들은 종종 올바른 공개 키를 공개하지만, 잘못된 발급자 또는 수신자를 가진 토큰을 수용하거나, 토큰 헤더에서 제공된 암호화 알고리즘 선택을 신뢰합니다. 암호화 서명은 유효할 수 있지만, 인증 결정을 아직 잘못합니다.
운영 환경도 중요합니다. 제품이 자주 릴리스되고, 고객을 대면하는 모바일 경험에 의존하는 경우, 팀은 2026년 소매 앱 참여 전략 업데이트完整성은 빠른 실험을 위한 필수 조건으로 다루어야 합니다. 빠른 배포는 릴리스 채널, 아티팩트, 수신자 모두 동일한 인증 결정을 바탕으로 한 경우에만 유용합니다.
완전한 인증 흐름 구축
생산 업데이터는 인증을 게이트로, 설치 시점 근처에서 실행되는 콜백으로 다루지 않아야 합니다. 안전한 순서는 결정적입니다:
- 인증된 전송을 통해 매니페스트와 서명 가져오기.
- 매니페스트 구조, 버전 정책, 채널, 만료, 아티팩트 식별성을 검증합니다.
- 매니페스트에 명시된 정확한 번들을 다운로드합니다.
- 번들의 해시를 지역적으로 계산합니다.
- 인증된 서명과 Ed25519 또는 RSA-PSS 공개 키를 사용하여 서명 확인합니다.
- 인증된 아티팩트를 격리된 위치에 저장합니다.
- 원자적으로 적용하고 롤백 경로를 유지합니다.
manifest는 모든 결정에 영향을 미치는 값이 모두 바인딩되어야 합니다. 최소한, 버전, 채널, 플랫폼, 키 식별자, 그리고 번들 디지스트가 포함되어야 합니다. 다운로드자가 검증 후 URL, 파일 이름, 또는 채널을 대체하지 않도록 하십시오. 검증기는 불변 바이트와 불변 메타데이터를 받고, 단일 승인 또는 거부 결과를 반환해야 합니다.
TypeScript 형태는 다음과 같습니다:
type UpdateManifest = {
version: string
channel: string
platform: string
sha256: string
signature: string
keyId: string
}
async function verifyBundle(
bundle: Uint8Array,
manifest: UpdateManifest,
trustedKeys: Map<string, Uint8Array>
): Promise<boolean> {
const publicKey = trustedKeys.get(manifest.keyId)
if (!publicKey) return false
const digest = await sha256(bundle)
if (!constantTimeEqual(digest, hexToBytes(manifest.sha256))) {
return false
}
try {
return await ed25519Verify(
base64ToBytes(manifest.signature),
digest,
publicKey
)
} catch {
return false
}
}예제는 의도적으로 엄격합니다. 잘못된 base64, 알려지지 않은 키 식별자, 디지스트 불일치, 또는 서명 실패는 모두 거부를 발생시켜야 합니다. 다운로드 중 시간 초과는 이전 부분 파일을 적용하는 이유가 아닙니다. 불완전한 아티팩트를 삭제하고 마지막으로 알려진 좋은 버전을 보존한 후, 제한된 정책 하에서 다시 시도하십시오.
경쟁과 롤백 오류를 방지하는 방법
임시 경로로 다운로드하십시오. 파일을 닫고 플러시한 후, 완전한 내용을 검증한 후, 버전화된 검증된 저장소로 이름을 바꿀 수 있습니다. 활성화 단계는 검증된 경로만 참조해야 합니다. Capacitor 및 Electron 환경에서, 비동기 다운로드 완료 이벤트가 검증 프로미스 independent로 활성화되도록 허용하지 마십시오. 단일 업데이트 상태 머신은 다음과 같은 전환을 소유해야 합니다. downloading, verified, pending, active, rejected, rolled_back.
비밀번호 byte 시퀀스를 비교할 때 상수 시간 비교가 적절합니다. 공격자가 반복적인 검증 동작을 관찰할 수 있는 경우 특히 그렇습니다. 더 중요한 운영상으로는, 이전에 시도한 버전이 사용 가능하다고 표시한 경우에 버전 번호를 받는 단축키를 노출하지 마십시오. 사용 가능성과 진위성은 별개의 상태입니다.
The Capacitor 업데이트의 체크섬 검증과 활성화 논리 구분을 위한 유용한 구현 참고 자료입니다. 실패 branch를 의도적으로 테스트하고, 잘라낸 파일, 서명이 손상된 파일, 알려지지 않은 키, 만료된 매니페스트, 중복된 버전, 활성화 중 프로세스 종료와 같은 경우를 포함하여.
자동 서명 검증에 대한 연구는 다른 영역에서 임계값과 참조 데이터의 중요성을 보여주고 있습니다. 1994년 온라인 연구는 22 개의 특징, 가장 좋은 10, 보고한 99.5% 진정한 서명에 대한 올바른 분류를 하면서 86% 위조된 서명 을 Euclidean 거리법에 따라 에 따라 기술했습니다. 통계적 방법 연구에 따르면. 소프트웨어 업데이트의 검증은 생체 인증과 다르지만, 이 교훈은 여전히 관련이 있습니다: 입력과 결정 경계를 명확히 정의하십시오.
키 관리 과제 대부분의 팀이 저평가한다
첫 번째 서명 키는 쉽다. 두 번째 키는 아키텍처가 테스트되는 곳이다.
팀은 키 pairs를 생성하고, 공개 키를 앱에 넣고, 첫 번째 번들을 일일이 서명할 수 있다. 몇 달 후, 엔지니어가 랩탑에 접근하고 CI secret가 빌드 로그에 출력되거나, 서명 작업이 하나의 실행자에서 다른 실행자로 이동해야 하는 경우가 있다. 그 때, “키를 회전하세요”라는 말은 기기들이 체크인하지 않고, 새로운 키를 인식할 수 없는 기기들을 버려야 하는 경우가 있다.
첫 번째 릴리즈 전에 디자인에 주목해야 할 세 가지 문제가 있다:
- 회전이 죽은 곳 없이: 후계 키를 승인하기 전에, 그 키를 요구하지 말라. 기존에 신뢰된 키가 다음 키를 승인할 수 있도록, 기존 키가 계속해서 앱에 사용되도록 정의된 마이그레이션 윈도우 동안 기존 키를 신뢰할 수 있도록 서명된 키 전환 기록을 사용하라.
- 첫 번째 키가 자동으로 OCSP 또는 CRL-style revocation을 제공하는 것은 아니다. 클라이언트는 서명된 거부 목록, 최소 허용 키 버전, 또는 네트워크가 불안정할 때도 안전한 서버 제어 정책이 필요하다. 제한된 서명 접근 권한:
- 인증 제한 접근: CI 실행자는 보관소나 HSM에서 서명 연산을 요청해야 하며, 재사용 가능한 개인 키를 평문 환경 변수로 받지 말아야 합니다. 로그는 명령어 출력을 가리고, 신뢰할 수 없는 branch의 pull request는 프로덕션 서명 인증서에 도달하지 않아야 합니다.
실무 현실: 키 회전은 업데이트의 문제입니다. 업데이트기능이 신뢰 변경을 안전하게 전달할 수 없다면, compromized 키로부터 깨끗하게 복원할 수 없습니다.
키 계층 구조는 폭파 반경을 줄입니다. 루트 권한자는 릴리즈 키를 승인할 수 있으며, 별도의 키는 개발, 스테이징, 프로덕션 채널을 각각 서명합니다. 다중 서명은 sensitive 프로덕션 릴리즈를 위해 여러 인증된 파티가 필요합니다. 이는 하나의 훔친 인증서가 유효한 업데이트를 생성하는 것을 방지합니다. 이 제어는 프로세스와 지연을 추가하므로 팀은 업데이트의 영향과 채널의敏感성에 따라 이를 적용해야 합니다.
첫 번째 키가 배포 채널과 함께 도착하는 경우, 공격자가 채널을 통제하는 경우 첫 번째 키와 배포 패키지를 모두 교체할 수 있습니다. 초기 신뢰 어카운트는 앱 바이너리, 플랫폼 보호된 구성, 독립적으로 인증된 경로로 도착해야 합니다.
Capacitor 팀에게는 Capgo의 문서화된 방법이 있습니다. 이 방법에는 공개 키 핀닝 및 키 회전 지원이 포함되어 있습니다. 안전한 OTA 업데이트를 위한 키 관리 지침 키 관리 지침은 업데이트의 생명주기를 계획하는 데 있어 실제적인 참고 자료를 제공합니다. 키 생성을 단 한번의 설정으로만 다루지 말아야 합니다.
CI/CD 및 모니터링 통합
릴리즈 트랜잭션 내에서 서명이 속해야 합니다. pipeline은 릴리즈 트랜잭션의 서명이 포함된 버전을 먼저 배포하고 나중에 별도의 수동 단계를 통해 서명이 포함된 버전을 배포하는 것이 아닙니다. 불변 아티팩트를 빌드하고, 아티팩트의 해시를 계산하고, 정확한 바이트를 서명하고, 깨끗한 검증 단계를 통해 서명이 유효한지 확인하고, 릴리즈 단위로 버전, 채널, 플랫폼, 해시, 키 식별자, 롤아웃 정책과 함께 버블과 메타데이터를 배포합니다.
실용적인 pipeline은 이러한 아티팩트를 생성합니다:
- 불변 버블: 클라이언트가 다운로드하는 파일, CDN이 재패키징하는 디렉토리가 아닌.
- 매니페스트: 버전, 채널, 플랫폼, 해시, 키 식별자, 롤아웃 정책.
- 분리된 서명: canonical 매니페스트 데이터 또는 정의된 해시 표현에 대한 서명.
- 검증 결과: 서명이 환경에 대한 공개 키와 유효한지 확인하는 기계가 읽을 수 있는 검증 결과.
GitHub Actions 및 GitLab CI는 문법이 다르지만 동일한 패턴을 강제할 수 있습니다. 서명 서비스가 unavailable, 서명이 잘못된 경우, 또는 새로 다운로드한 테스트 복사본이 검증되지 않는 경우 서명 작업은 실패해야 합니다. 배포 작업은 그 결과에 의존해야 하며, 단지 빌드가 성공한 경우에만 의존해야 합니다.
경로를 변경하지 말고 나중에 작업이 경로를 변형시키지 못하게 하라. artifact를 서명한 후 lock하고, publicize하기 전에 digest를 비교하고, release record에서 reproducible한 manifest를 생성하라. CI 작업이 압축된 아카이브를 서명하는 동안 배포层가 재압축된 또는 재생성된 파일을 제공하는 통합 결함을 잡을 수 있다.
장치에 관찰 가능성을 두어라.
성공적인 서명 작업은 pipeline이 유효한 서명을 생성했다는 것을 증명한다. 그러나 장치가 의도한 바이트를 받았는지, 앱이 의도한 키를 사용했는지 증명하지 않는다. 앱 버전, 업데이트 버전, 채널, 플랫폼, 키 식별자, 결과 카테고리, 그리고 개인 정보 보호를 위한 release correlation ID와 함께 verification 결과를 기록하라. 배달, 토큰, 개인 메타데이터, 또는 사용자 콘텐츠를 로깅하지 마라.
유용한 대시보드는 다음과 같이 구분한다:
- 서명 실패와 다운로드 실패를 구분하라.
- digest 불일치와 잘못된 manifest를 구분하라.
- 알 수 없는 키와 정책 거부를 구분하라.
- 버전, 지역, 채널, 및 릴리스 나이에 따라 실패를 구분하라.
갑자기 발생하는 digest 불일치의 클러스터는 캐시가 손상되었거나 배포 경로가 변경되었거나 artifact가 잘못된 위치에 게시되었다는 것을 나타낼 수 있다. 알 수 없는 키 이벤트는 완전한 회전이 완료되지 않았거나 비인가된 릴리스 시도라는 것을 나타낼 수 있다. verification telemetry는 공격자를 직접 식별하지는 못하지만, 공격자가 발생한 시점과 발생한 인구를 조사할 수 있게 해준다.
The Capacitor 업데이트 워크플로우에서 서명, 검증 및 배포 게이트를 한 번에 설치할 수 있도록 팀을 도와줄 수 있습니다. 중요한 디자인 선택은 소유권입니다. 보안은 검증이 실행되었는지 엔지니어에게 물어볼 필요가 없습니다. 릴리스 기록과 클라이언트 테레미터리는 그에 대한 직접적인 답변을 제공해야 합니다.
보안 최적화 방법 및 일반적인 오류
모든 업데이트 경로에서 code이 실행될 수 있는 경우 서명 검증이 필수적이어야 합니다. 업데이터는 추출, 설치 또는 활성화 전에 검증을 수행해야 하며 서명, 해시, 키 또는 정책 검증이 불가할 경우 실패해야 합니다.
이것을 즉시 검토 목록으로 사용하세요:
- 개인 키를 보호하세요: 서명 자료를 HSM 또는 관리되는 보관소에 저장하세요. 소스 제어에 넣지 마세요. 모바일 바이너리에 넣지 마세요. CI 로그에 넣지 마세요.
- 신뢰할 수 있는 공개 키를 고정하세요: 업데이트 페이로드 외부에 초기 신뢰 주체를 저장하세요. 여러 키를 지원하는 경우 그들의 목적과 전환 규칙을 정의하세요.
- 완전한 릴리스를 결합하세요: 정확한 버블, 채널, 플랫폼 및 정책을 식별하는 캔온리 메타데이터를 서명하세요.
- 모든 검증 오류를 거부하세요: 시간 초과, 서명이 잘못된 경우, 알려지지 않은 키, 또는 매니페스트가 누락된 경우 이전에 검증되지 않은 결과를 계속 진행하는 것은 초대가 아닙니다.
- 테스트 복원력 회복: 스테이징에서 키 회전, 취소된 키 처리, 롤백, 중단된 다운로드 및陈舊 장치에 대한 연습.
- 검증기 변경 검토: 암호화 라이브러리, 정규화, 파싱, 대체 동작 및 디버그 구성에 대한 보안에 중점을 둔 code 검토를 요구하십시오.
- 디버그 동작을 분리하십시오: 개발자 우회는 기본 플래그 또는 환경 오류로 프로덕션 빌드에 패키지화 될 수 없어야 합니다.
서명도 신선함, 수신자 결합, 재생 방지 또는 제공자의 현재 상태와 호환되는 데이터가 유지되는 것을 증명하지 않습니다. 웹후크 보안 지침은 이러한 차이를 명확하게 설명하고 최근 취약성 보고서에서는 잘못된 또는 null 서명 및 정규화 문제가 좁은 검증 체크를 무너뜨릴 수 있음을 보여주었습니다. 웹후크 보안 분석을 설계할 때 주변 인증 규칙을 읽으십시오.
임계값 선택은 생체 인식 시스템에서 관련된 교훈을 제공합니다. 102명의 개인에서 1,232개의 서명에 대해 62개의 매개변수 특성을 사용한 연구는 102명의 개인에서 1,232개의 서명에 대해 62개의 매개변수 특성을 사용한 연구는 on 102명의 개인에서 1,232개의 서명에 대해 62개의 매개변수 특성을 사용한 연구는 102명의 개인에서 1,232개의 서명에 대해 62개의 매개변수 특성을 사용한 연구는 2.8% 거짓 거부율 and 1.6% 거짓 수락율또는 다른 방법이 2.68% 거짓 거부율 and 1.99% 거짓 수락율, threshold-selection 연구 .
Capgo은 Capacitor와 Electron 팀이 서명된 라이브 업데이트 패키지, 장치 내 검증, 롤아웃 제어, 롤백 보호 및 전달 관찰 가능성을 같은 시스템에서 제공하는 구현 옵션으로 사용할 수 있습니다. Capgo 업데이트 워크플로우가 키 관리, CI/CD, 모니터링 요구 사항과 일치하는지 평가하는 방법을 찾고 있습니다.
