__CAPGO_KEEP_0__ 인증: 2026년 앱 업데이트 보안

Your update pipeline is green, the bundle is available at the edge, and devices are checking for it. Then someone notices a suspicious change in the generated JavaScript. A compromised build runner, stolen developer credential, or altered artifact may have slipped a malicious payload into the release after testing finished. Without signature verification클라이언트는 배포된 패키지를 공격자가 수정한 것과 구분할 수 있는 방법이 없습니다.

서명된 업데이트는 이 결정을 바꿉니다. 장치에서는 현재 실행 중인 code을 교체하기 전에 패키지를 신뢰할 수 있는 공개 키와 비교합니다. 서명이 일치하지 않으면 업데이트는 비활성화 상태로 유지됩니다. 이게 직관적처럼 보이지만, 실제로 프로덕션 오류는 암호화에 관련된 것이 아니라 암호화 자체에 있습니다. 팀은 키 회전을 추적하지 못하고, 올바른 아티팩트에 서명하지 못하고, 검증되지 않은 캐시된 파일을 적용하거나, 업데이트를 거부한 장치에 대한 정보를 거의 수집하지 못하여, 업데이트를 거부한 장치가 무엇인지 설명할 수 없습니다.

다음 섹션에서는 신뢰 모델, 검증 흐름, CI/CD 제어, 사고 대응 및 서명 자체로 해결되지 않는 한계까지의 운영 경계를 다룹니다.

서명 검증이 재난적 업데이트를 방지하는 이유
암호학적 서명이 신뢰를 창조하는 방법
- 모바일 배포를 위한 알고리즘 선택
- 신뢰 체인과 고정된 키
모바일 및 웹 시스템에서 실용적인 응용
완전한 검증 흐름을 구축하는 방법
- 경쟁과 롤백 오류를 예방하는 방법
키 관리를 가장 과소평가하는 팀의 문제
CI/CD 및 모니터링 통합
- 장치에 관찰성
보안最佳 관행 및 일반적인 함정

대규모 업데이트를 방지하는 서명 확인의 이유

A popular Capacitor plugin’s CI/CD pipeline is compromised late in the release process. The attacker modifies the live update bundle, adds code that reads application data, and publishes the artifact using the pipeline’s normal delivery path. Devices don’t see an unfamiliar download domain. They see a valid update waiting for installation.

서명 확인이 없는 클라이언트 측 암호화 검사 시 앱은 업데이트 정책이 허용하는 즉시 수정된 패키지를 다운로드하고 실행할 수 있습니다. 데이터 유출, 자격 증명 도난, 지불 흐름 변경 및 비밀스러운 비즈니스 논리 조작의 가능성이 포함된 폭발적인 범위가 있습니다. 조사도 고통스럽습니다. 엔지니어들은 어떤 artifact가 제공되었는지, 어떤 채널이 그것을 받았는지, 어떤 장치가 그것을 다운로드했는지, 어떤 장치가 그것을 적용했는지, 그리고 악성 code가 릴리스가 취소되기 전에 실행되었는지 여부를 결정해야 합니다.

소프트웨어 업데이트 전달 pipeline에서 악성 code 주입을 차단하는 다이어그램

서명 확인이 활성화된 팀은 다른 실패 모드를 얻습니다. 앱은 동일한 오염된 패키지를 다운로드하고 예상 해시를 계산한 다음 신뢰할 수 있는 키와 함께 첨부된 서명과 비교합니다. 암호화 확인이 실패하고 업데이터는 패키지를 활성화 거부하고 새로운 code이 실행되기 전에 보안 팀에 이벤트가 도달합니다.

생산 규칙: 업데이트를 호스트로 간주할 때까지 장치가 자신의 정체성과 정확한 바이트를 확인할 때까지 업데이트를 호스트로 간주하십시오.

인증자만 장치에서 실행되고 추출 또는 활성화 전에만 보호가 작동하며 신뢰할 수 있는 키가 업데이트 자체로 대체되지 않는다면만 작동합니다. 따라서 인증서 및 키 관리는 업데이트 디자인의 일부가 아닌 관리 세부 사항이 됩니다. Capacitor을 사용하는 팀은 인증서 관리 프로세스와 함께 이 경계를 문서화해야 합니다. 인증서 관리 프로세스, 업데이트가 서명할 수 있는 사람, 키가 어디에 있는지, 클라이언트가 승인된 후속 키에 대해 학습하는 방법을 포함하여.

현대 연구는 서명 확인을 수십 년 동안 측정 가능한 엔지니어링 분야로 다루고 있습니다. 1977년 처음 발표된 오프라인 및 온라인 서명 확인 연구는 이후 HMM 및 FFT와 같은 다양한 방법으로 확장되었습니다. 널리 인용된 비교 보고서는 인간 전문가의 경우約 0.5%의 허위 승인과 7%의 허위 거부를 기록했으며 일반인들은 약 6.5%의 허위 승인과 26%의 허위 거부를 기록했습니다. 이 서명 확인 연구의 역사적 개요를 참조하십시오. __CAPGO_KEEP_0____CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__ __CAPGO_KEEP_0__이 통계는 소프트웨어 업데이트와 관련이 없지만, 검증의 품질은 검증자, 참조 데이터 및 결정 정책에 의존한다는 점을 강조한다.

암호학적 서명이 신뢰를 창출하는 방법

배포 패키지를 생각하면, 그것은 봉투와 같다. 빌드 시스템은 정확한 바이트의 해시를 계산하고, 개인 키 해시를 사용하여 그에 대한 디지털 서명을 생성한다. 앱은, 또는 안전하게 받은, 해당 공개 키가 있다. 그것은 봉투에 있는 알려진 문장과 같다. 만약 공격자가 패키지의 작은 부분을 변경한다면, 앱은 다른 해시를 계산하고 서명이 더 이상 유효하지 않게 된다.

개발자가 서명을 생성하는 것부터 모바일 앱 검증까지의 암호학적 서명 프로세스를 minh họa하는 다이어그램이다.

이 흐름은 네 가지 구별된 부분으로 구성된다.

해싱 패키지를 고정 길이의 해시로 변환한다. SHA-256 및 SHA-512은 이 무결성 단계에서 일반적으로 사용되는 선택이다.
키 생성 비대칭 pair를 생성합니다. private key는 서명하고, public key는 확인합니다.
서명 해시를 릴리즈 메타데이터와 결합합니다. 버전, 채널, 플랫폼, 그리고 대상 audience를 포함하는 것이 좋습니다.
인증 다운로드한 바이트에서 해시를 재계산하고, 신뢰할 수 있는 private key가 서명한 것을 확인합니다.

인증자는 업데이터가 적용할 payload와 동일한 payload와 서명을 결합해야 합니다. manifest에 대한 서명만으로는 앱이 나중에 bundle을 다운로드하고, manifest의 해시가 bundle과 일치하는지 확인하지 않으면 충분하지 않습니다. 또한, bundle의 해시만을 확인하여 인증하는 것은, 해시 자체가 인증되지 않은 경우, 누구가 이를 승인했는지 알 수 없습니다.

모바일 배포를 위한 알고리즘 선택

RSA는 친숙하고 널리 지원되지만, 보통 더 큰 키 자료와 주의 깊은 패딩 선택이 필요합니다. 새로운 모바일 업데이트 프로토콜에서 Ed25519는 종종 매력적이기 때문에, 키와 서명이 compact하고, 모바일 프로세서에서 인증 경로가 효율적입니다. RSA-PSS는 호환성 요구 사항이 RSA가 필요할 때도 적절할 수 있습니다. 선택은 플랫폼 암호 라이브러리, 지원되는 하드웨어, 호환성 요구 사항, 그리고 마이그레이션 계획에 따라야 하며, 다른 환경에서 복사한 벤치마크에 따라서는 아닙니다.

이용 가능한 독립적인 소개는 블록체인에 대한 이 가이드를 통해 이해하는 암호학적 서명입니다. 블록체인에 대한 암호학적 서명 이해. OTA 배포와의 transaction context는 다르지만, private-key 인증과 public-key 인증에 대한 설명은 직접적으로 전달됩니다.

신뢰 체인과 고정 키

인증 체인은 신뢰를 루트에서 중간 인증 기관을 통해叶자 인증서로 전달합니다. 이 모델은 광범위한 PKI 작업을 단순화할 수 있지만 앱 업데이트한 클라이언트는 일반적으로 좁은 요구 사항을 갖습니다: 이 업데이트를 승인 한 출판자 키만 신뢰하십시오. 앱 바이너리에 공개 키 또는 승인된 키의 작은 집합을 직접埋め込는 것은 고정 키의 한 형태입니다. 이 방법은 외부 인증 기관에 대한 의존성을 줄이지만 바이너리가 이미 새로운 키를 신뢰해야 하는 교체 키 문제를 생성합니다.

완전한 서명된 편지함을 유지하십시오. 릴리스 메타데이터는 아티팩트, 해시, 목표 채널, 키 식별자와 같은 정보를 포함해야 합니다. 이 기능을 구현하는 팀은 Capacitor를 사용하여 Capacitor 앱에 대한 고정된 Capacitor 앱의 키 범위, 저장소 및 검증 경계를 검토하기 전에 배송하기 위한 token-signing 체크리스트를 사용할 수 있습니다. 모바일 및 웹 시스템의 실제 응용 사례

서명 검증은 모바일 제품의 여러 층에 나타나며 각 층은 다른 질문에 답합니다. 앱 스토어 인증은 운영 체제가 설치 가능한 패키지가 권한 있는 출판자로부터 왔는지 결정하는 데 도움이 됩니다. signed OTA 배달은 JavaScript 및 자산 페이로드가 릴리스 권한을 신뢰하는 업데이터가 신뢰하는 출처로부터 왔는지 여부를 결정하는 데 도움이 됩니다. JWT 서명은 __CAPGO_KEEP_0__가 예상한 식별 서비스가 토큰을 발행했는지 확인하는 데 도움이 됩니다.

Signature verification appears in several layers of a mobile product, and each layer answers a different question. App-store signing helps the operating system decide whether an installable package comes from an authorized publisher. A signed OTA bundle answers whether the JavaScript and asset payload came from the release authority your updater trusts. A JWT signature helps an API validate that a token was issued by the expected identity service.

layer를 혼동하는 것은 결함을 발생시킨다. 유효한 IPA 서명은 자동으로 후속 웹 패키지를 인증하지 않는다. 유효한 JWT는 업데이트 패키지가 안전하다는 것을 증명하지 않는다. TLS 연결은 수송을 보호하지만, CDN, 프록시, 캐시 또는 빌드 시스템이 변조의 원인이 되는 경우에는 artifact 서명 대체하지 않는다.

Context	서명 메커니즘	실패 모드 방지	일반적인 결함
앱 스토어 패키지	플랫폼 code-서명 및 플랫폼 검토 제어	재 서명 또는 권한이 없는 설치 가능한 패키지	팀은 스토어 서명이 설치 후 웹 자산을 커버한다고 가정한다.
웹 패키지 및 서비스 워커	서명된 교환 또는 SRI-스타일完整성 참조	중독된 CDN 응답 또는 수정된 자산	만들어진 파일만 검사되며, 임포트된 자산은 검증되지 않습니다.
API 토큰	JWT 서명은 신뢰할 수 있는 공개 키를 통해 검증되며, 일반적으로 JWKS 엔드포인트를 통해 얻습니다.	위조된 또는 변조된 토큰	서버는 서명이 유효하지만, 발급자, 수신자, 만료일, 또는 토큰 목적을 무시합니다.
OTA 업데이트	디바이스에서 분리된 또는 임베디드된 패키지 서명이 검증됩니다.	인터넷 공격자 또는 변조된 업데이트가 주입됩니다.	클라이언트는 콘텐츠를 다운로드, 캐시, 또는 압축하기 전에 결정을 강제합니다.

웹 자산의 경우, subresource integrity는 브라우저가 참조한 리소스에 대해 받을 수 있는 것을 제한할 수 있지만, 동적 임포트, 서비스 워커 캐시, 또는 업데이트한 매니페스트가 공격자 선택한 파일을 참조하는 경우 자동으로 해결되지 않습니다. 구현은 완전한 아티팩트 세트를 정의하고 실행할 bytes를 검증해야 합니다.

JWT 배포는 다른 방식으로 실패합니다. 개발자들은 종종 올바른 공개 키를 공개하지만, 잘못된 발급자 또는 수신자를 가진 토큰을 수용하거나, 토큰 헤더에서 제공한 암호화 알고리즘 선택을 신뢰합니다. 암호화 서명은 유효할 수 있지만, 인증 결정을 아직 잘못된 경우가 있습니다.

운영 환경도 제품이 자주 릴리스되고 고객을 대면하는 모바일 경험에 의존하는 경우 중요합니다. 평가하는 2026년 소매 앱 참여 전략 업데이트完整성을 신속한 실험에 대한 전제로 다루어야 합니다. 빠른 배포는 릴리스 채널, 아티팩트, 수신자 모두 동일한 인증 결정을 바탕으로 한 경우에만 유용합니다.

완전한 검증 흐름 구축

생산 업데이트기는 검증을 게이트로, 설치 위치에서 실행되는 콜백으로 다루지 않아야 합니다. 안전한 순서는 결정적입니다:

인증된 전송을 통해 매니페스트와 서명 가져오기.
매니페스트 구조, 버전 정책, 채널, 만료, 아티팩트 식별성을 검증하기.
매니페스트에 명시된 정확한 버ंडल 다운로드.
로컬에서 버ndl 디지스트 계산하기.
trusted Ed25519 또는 RSA-PSS 공개 키에 서명 검증하기.
검증된 아티팩트를 격리된 위치에 저장하기.
원자성으로 적용하고 롤백 경로 유지하기.

소프트웨어 업데이트 버들에 대한 fetching, 서명 검증 및 유효성 검사 프로세스를 minh họa하는 네 단계 다이어그램.

만들어야 할 매니페스트는 모든 결정에 영향을 미치는 모든 값을 바인딩해야 합니다. 최소한, 버전, 채널, 플랫폼, 키 식별자, 그리고 번들 다이제스트를 포함해야 합니다. 다운로드자가 검증 후 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, and rolled_back.

敏감한 바이트 시퀀스를 비교할 때, 공격자가 반복적인 검증 동작을 관찰할 수 있는 경우에는 상수 시간 비교가 적절합니다. 더 중요한 운영 관점에서, 이전 시도에서 버전을 사용 가능한 것으로 표시한 경우에 버전을 받는 단축키를 공개하지 마십시오. 사용 가능성과 진위성은 별개의 상태입니다.

The Capacitor 업데이트의 체크섬 검증 및 활성화 논리 구분을 위한 유용한 구현 참고 자료입니다. 실패 branch를 의도적으로 테스트하십시오. 잘라진 파일, 서명이 손상된 파일, 알려지지 않은 키, 만료된 매니페스트, 중복된 버전, 활성화 중 프로세스 종료와 같은 경우를 포함하십시오.

자동 서명 검증에 대한 연구는 다른 영역에서 임계값과 참조 데이터의 중요성을 보여줍니다. 1994년 온라인 연구는 22 개의 특징을 선택하고 10보고했습니다. 99.5% 진정한 서명을 올바르게 분류하고 86% 위조 서명을 거부했습니다. 에 따라 Euclidean 거리법을 사용한 통계적 방법 연구에 의거합니다.

키 관리 과제 대부분의 팀이 저평가한다

첫 번째 서명 키는 쉽다. 두 번째 키는 아키텍처가 테스트되는 곳이다.

팀은 키 pairs를 생성하고, 공개 키를 앱에 넣고, 첫 번째 번들을 1일 내에 서명할 수 있다. 몇 달 후, 엔지니어가 laptop에 접근하고 CI secret가 빌드 로그에 출력되거나, 서명 작업이 하나의 러너에서 다른 러너로 이동해야 하는 경우가 있다. 그 때, "키만 회전하라"는 의미는 장치가 체크인하지 않고, 새로운 키를 인식할 수 없는 장치가 있는 경우에 "장치가 버려지게 된다"는 것이다.

단순한 한 번의 키 설정과 복잡한, 지속적인 생산 현실의 차이를 비교하는 그래픽.

첫 번째 릴리스 전에 디자인에 주목할 만한 세 가지 문제가 있다:

회전이 죽은 곳에 도달하지 않도록: 후계 키에 대한 신뢰를 배달하기 전에 그 키를 요구하지 말라. 기존에 신뢰받는 키가 다음 키를 승인할 수 있도록, 기존 키로 앱이 정의된 마이그레이션 기간 동안 계속해서 이전 키를 받아들이도록, 서명된 키 전환 기록을 사용하라.
첫 번째 키가 앱에 내장된 경우, OCSP나 CRL-style revocation이 자동으로 제공되지 않는다. 클라이언트는 서명된 거부 목록, 최소 허용되는 키 버전, 또는 네트워크가 불능일 때도 안전한 서버 제어 정책이 필요하다. 제한된 서명 접근 권한:
__CAPGO_KEEP_0__ CI 실행자는 보관소 또는 HSM에서 서명 연산을 요청해야 하며 재사용 가능한 개인 키를 평문 환경 변수로 받지 말아야 합니다. 로그는 명령어 출력을 가리고, 신뢰할 수 없는 branch에서 pull request는 프로덕션 서명 인증서에 도달하지 않아야 합니다.

실무 현실: 키 회전은 업데이트의 문제입니다. 업데이트기능이 신뢰 변경을 안전하게 전달할 수 없다면, compromized 키로부터 깨끗하게 복원할 수 없습니다.

키 계층 구조는 폭파 반경을 줄입니다. 루트 권한자는 릴리즈 키를 승인할 수 있으며, 별도의 키는 개발, 스테이징 및 프로덕션 채널을 서명합니다. 임계점 서명은 민감한 프로덕션 릴리즈를 위해 여러 인증된 파티가 필요합니다. 이는 하나의 도난된 인증서가 유효한 업데이트를 생성하는 것을 방지하는 데 도움이 됩니다. 이 제어는 프로세스 및 지연성을 추가하므로 팀은 업데이트의 영향과 채널의敏감도에 따라 이를 적용해야 합니다.

첫 번째 키가 패키지와 같은 채널을 통해 도착하는 경우, 공격자가 해당 채널을 제어하는 경우 첫 번째 신뢰의 근거는 특히 모바일 업데이트에서 약합니다. 초기 신뢰의 근거는 앱 바이너리, 플랫폼 보호된 구성, 또는 독립적으로 인증된 경로로 도착해야 합니다.

Capacitor 팀에게는 Capgo의 문서화된 방법이 있습니다. 이 방법에는 공개 키 핀닝 및 키 회전 지원이 포함됩니다. 보안 OTA 업데이트를 위한 키 관리 지침 업데이트 생명주기를 계획하는 데 있어 이 지침은 키 생성을 단순한 초기 설정으로 다루는 대신 실용적인 참고 자료입니다.

CI/CD 및 모니터링 통합

릴리스 트랜잭션 내에서 서명이 속해야 합니다. pipeline은 릴리스 트랜잭션의 서명이 포함된 버전을 먼저 배포하고 나중에 별도의 수동 단계를 통해 서명이 첨부되는 버전을 배포하지 않아야 합니다. 불변 아티팩트를 빌드하고, 아티팩트의 해시를 계산하고, 정확한 바이트를 서명하고, 깨끗한 검증 단계를 통해 서명이 유효한지 확인하고, 릴리스 단위로 버전, 채널, 플랫폼, 해시, 키 식별자 및 롤아웃 정책과 함께 버그와 메타데이터를 배포해야 합니다.

실용적인 pipeline은 다음 아티팩트를 생성합니다:

불변 버그: 클라이언트가 다운로드하는 파일, CDN이 재패키징하는 디렉터리가 아닌.
매니페스트: 버전, 채널, 플랫폼, 해시, 키 식별자 및 롤아웃 정책.
분리된 서명: canonical 매니페스트 데이터 또는 정의된 해시 표현에 대한 서명.
검증 결과: 서명이 기대하는 환경의 공개 키와 유효한지 확인하는 기계가 읽을 수 있는 검증.

GitHub Actions 및 GitLab CI는 같은 패턴을 강제할 수 있지만, 문법이 다르다. 서명 작업은 사설 서명 서비스가 unavailable, 서명이 잘못된 경우, 또는 최신 다운로드 테스트 복사본이 검증되지 않은 경우 실패해야 합니다. 배포 작업은 그 결과에 의존해야 하며, 단지 빌드가 성공한 경우에만 의존해야 합니다.

경로를 변경하지 말고 나중에 작업이 경로를 변경할 수 있게 해서는 안 됩니다. 서명 후에 artifact를 잠그고, 배포 전에 서명 전의 해시를 비교하고, 릴리스 기록으로부터 배포 매니페스트를 재생성할 수 있도록 하세요. CI 작업이 압축된 아카이브를 서명하는 동안 배포层가 재압축된 파일이나 재생성된 파일을 제공하는 통합 간극을 잡을 수 있습니다.

관찰성은 장치에 속해야 합니다.

성공적인 서명 작업은 pipeline이 유효한 서명을 생성했다는 것을 증명합니다. 그러나 장치가 의도한 바이트를 받았는지, 앱이 의도한 키를 사용했는지 증명하지는 않습니다. 앱 버전, 업데이트 버전, 채널, 플랫폼, 키 식별자, 결과 카테고리, 그리고 개인 정보 보호된 릴리스 상관 ID와 함께 검증 결과를 기록하세요. 배포, 토큰, 개인 정보 보호된 메타데이터, 또는 사용자 콘텐츠를 로깅하지 마세요.

유용한 대시보드는 다음과 같이 구분합니다:

서명 실패와 다운로드 실패를 구분합니다.
해시 불일치와 잘못된 매니페스트를 구분합니다.
알 수 없는 키와 정책 거부를 구분합니다.
버전, 지역, 채널, 및 릴리스 나이에 따라 실패를 구분합니다.

갑자기 발생하는 해시 불일치가 캐시가 손상된 것, 배포 경로가 변경된 것, 또는 artifact 배포 오류를 나타낼 수 있습니다. 알 수 없는 키 이벤트는 완전한 회전이 완료되지 않았거나 비인가된 릴리스 시도인 경우입니다. 검증 통계는 공격자를 직접 식별하지는 않지만, 공격자가 발생한 시점과 공격자가 발생한 인구를 알려줍니다.

CI/CD 보안 지침 Capacitor OTA 업데이트에 대한 업데이트 워크플로우에서 서명, 검증 및 배포 게이트를 한 번에 설치할 수 있도록 팀을 도와줄 수 있습니다. 중요한 설계 선택은 소유권입니다. 보안은 검증이 실행되었는지 엔지니어에게 물어볼 필요가 없습니다. 릴리스 기록과 클라이언트 테스트 메트릭은 직접 그 답을 제공해야 합니다.

보안 최적화 방법 및 일반적인 오류

모든 업데이트 경로가 code을 실행할 수 있는 경우 서명 검증이 필수적이어야 합니다. 업데이터는 추출, 설치 또는 활성화 전에 검증을 수행해야 하며 서명, 해시, 키 또는 정책 검증이 불가할 경우 실패해야 합니다.

이것을 즉시 검토 목록으로 사용하세요:

개인 키를 보호하세요: 서명 자료를 HSM 또는 관리형 보관소에 저장하세요. 소스 제어에 넣지 마세요. 모바일 바이너리에 넣지 마세요. CI 로그에 넣지 마세요.
신뢰할 수 있는 공개 키를 고정하세요: 초기 신뢰 주체를 업데이트 페이로드 외부에 저장하세요. 여러 키를 지원하는 경우 그 목적과 전환 규칙을 정의하세요.
완전한 릴리스를 결합하세요: 정확한 버그, 채널, 플랫폼 및 정책을 식별하는 캔온리 메타데이터를 서명하세요.
검증 오류를 거부하세요: 시간 초과, 서명이 잘못된 경우, 알려지지 않은 키, 또는 매니페스트가 누락된 경우 이전에 검증되지 않은 결과를 계속 진행하는 것은 허용되지 않습니다.
테스트 복원력 회복: 스테이징에서 키 회전, 취소된 키 처리, 롤백, 중단된 다운로드 및陈舊 장치 테스트
검증기 변경 검토: code 암호화 라이브러리, 정규화, 파싱, 대체 동작 및 디버그 구성에 대한 보안에 중점을 둔 검토를 요구합니다.
디버그 동작을 분리 유지: 개발자 우회는 기본 플래그나 환경 오류로 프로덕션 빌드로 패키징 될 수 없어야 합니다.

서명도 신선함, 수신자 결합, 재생 방지, 또는 제공자의 현재 상태와 호환되는 데이터가 유지되는지 증명하지 않습니다. 웹후크 보안 지침은 이러한 차이를 명확하게 설명하고, 최근 취약성 보고서에서는 잘못된 또는 null 서명 및 정규화 문제가 좁은 검증 체크를 무너뜨릴 수 있음을 보여주었습니다. 웹후크 보안 격차 분석을 읽어 주변 인증 규칙을 설계할 때.

임계값 선택은 생체 인식 시스템에서 관련된 교훈을 제공합니다. 62 매개 변수 특성을 사용한 연구는 102 명의 개인에서 1,232 서명에서 작성자에 따라 임계값이 보고된 2.8% 거짓 거부율 그리고 1.6% 거짓 수락, 다른 방법이 2.68% 거짓 거부율 그리고 1.99% 거짓 수락, threshold-selection 연구.

Capgo는 Capgo를 사용하여 Capacitor와 Electron 팀이 서명된 라이브 업데이트 패키지, 장치 내 검증, 롤아웃 제어, 롤백 보호 및 전달 관찰 가능성을 동일한 시스템에서 제공할 수 있습니다. Capgo 업데이트 워크플로우가 고객 키 관리, CI/CD, 모니터링 요구 사항과 일치하는지 평가하는 데 도움이 됩니다.