智能卡上的 AppStore 分发证书/密钥?

发布于 2025-01-01 15:09:07 字数 168 浏览 0 评论 0原文

有没有人调查过Apple AppStore分发私钥/证书是否可以存储在智能卡上?我在一家大公司工作,该公司即将发布多个 iOS 应用程序,我们关心保护我们的生产分发密钥和证书的最佳方法。是否可以在智能卡上生成并存储这些密钥/证书,然后在签署应用程序进行分发时使用该智能卡?他们的特定智能卡供应商是否在 OSX 上运行良好?

Has anyone done any investigation as to whether the Apple AppStore distribution private key/certificate can be stored on a smartcard? I work for a large company that is about to release several iOS applications and we're concerned about the best way to protect our production distribution keys and certificates. Is it possible to generate and store these keys/certs on a smartcard and then use that smartcard when signing the app for distribution? Are their particular smartcard vendors that work well on OSX?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

小草泠泠 2025-01-08 15:09:07

鉴于您的证书及其匹配密钥在您的钥匙串中可用,您应该能够对任何应用程序进行代码签名。

智能卡服务 看起来像是将这些资产(证书+密钥)存储在智能卡上时所需的工具。

You should be able to code sign any app given that your certificate and its matching keys are available in your Keychain.

SmartCard Services looks like the tool you need for the case these assets (cert+keys) are stored on a smart card.

热血少△年 2025-01-08 15:09:07

企业计划可让您制作可在所有设备上运行的发行版本,而无需辞职。

发送您的密钥和颁发证书是不可取的,这不仅意味着任何拥有它们的人都可以以您的名义构建应用程序;但当你必须更新证书时也会出现问题。

虽然直接回答你的问题 - 是的,你可以将它们存储在你想要的任何地方。它们只是文件。

An Enterprise Program will let you make distribution builds that will run on all devices without needed to resign.

Sending your key & certificate out is unadvisable, not only does it mean that anyone who gets hold of them can build apps in your name; but it will also become problematic when you have to update the certificate.

Though in direct answer to your question - yes you can store them anywhere you want. They are just files.

雪化雨蝶 2025-01-08 15:09:07

编辑

在您发表评论、进一步调查并根据记忆后,有两个元素/文件可以对应用程序进行签名:

  1. 钥匙串:开发者/分发证书(由您向 Apple 请求分发证书)
  2. MobileProvision:配置配置文件(Apple 提供的证书,如果没有之前的钥匙串证书 #1,该证书将无效,并且由 Xcode 用于签署应用程序)

这两个文件位于不同的位置位置:

  1. 开发者证书位于钥匙串中,根据 wikipedia 默认情况下 < code>~/Library/Keychains (session)/Library/Keychains (system),并在检查了一下之后“keychain”实用程序应用程序,看来您可以在任何路径注册/创建任何 “.keychain” 文件。因此,我想您可以使用智能卡从外部 .keychain 文件添加证书,无需将它们复制到您的 mac (待验证,会令人惊讶/奇怪,但也许这些被克隆到某个缓存或其他地方)。我还没有对此进行测试,但是 Xcode 使用“Keychain 服务”使这些底层 .keychain 文件透明是有意义的。因此,Xcode 应该“自动”从外部钥匙串文件中找到证书。
  2. MobileProvision~/Library/MobileDevice/Provisioning Profiles/SOME-UUID.mobileprovision 恐怕您无法告诉 Xcode 查看其他路径。

在这两种情况下,我想您可能可以使用符号链接来欺骗应用程序(Xcode..)/服务(Keychain...)... (ln -s ...)

我希望这些信息可以帮助您完成这项工作...祝您好运!

不是那么离题,但我很想知道什么样的场景使这种安全性合法。再说一遍,只有苹果开发者管理员帐户拥有“上帝的力量”... 如果没有该帐户,证书几乎毫无用处,除非您正在进行临时/企业分发...

ENDOFEDIT


AFAIK,Apple 生成所有证书 = 文件。
您可以按照自己想要的方式保护这些文件,但无论如何,要签署应用程序,您需要在签名时将它们复制到 Mac 上。 (在特定位置,钥匙串,Xcode 获取它们的地方)
我怀疑任何“智能卡”或类似的解决方案都是可靠的...

您可以做的就是专用一台 Mac 来进行应用程序签名并确保其访问安全(通过智能卡、生物识别技术、只需登录名/密码...甚至是上锁的门! )

假设 AppStore 是您的目标:

恕我直言,害怕被盗的分发证书有点偏执并且无用
要向 AppStore 提交应用程序,您无论如何都需要 iTunes 帐户管理员帐户,这是唯一具有该功能的帐户。换句话说,如果没有该帐户,则无法将签名的包提交给 Apple。

因此,只有 itunes connect 管理员帐户/密码必须真正受到保护
(在最坏的情况下,我很确定苹果可以阻止/恢复被盗帐户)

并且使用该管理员帐户,您可以取消任何应用程序提交,撤销/重新生成所有证书...(没有应用程序是立即验证,您有大约 10 天的批准期来取消它,并通过电子邮件通知管理员)

EDIT:

After your comment, further investigations, and from memory, there are two elements/files to sign an app:

  1. Keychain: The Developer/Distribution Certificate (the one created by you to request a distribution certificate from apple)
  2. MobileProvision: The Provisioning profile (the certificate provided by Apple, which is invalid without the previous keychain certificate #1 and used by Xcode to sign an app)

These two files are at separate places:

  1. The developer certificate is in the keychain, according to wikipedia by default in ~/Library/Keychains (session) and /Library/Keychains (system), and after checking a bit with "keychain" utility app, it appears that you can register/create any ".keychain" file at any path. So I guess you can add your certificates from an external .keychain file using a smartcard, w/o copying them to your mac (to be verified, would be surprising/strange, but maybe these are cloned to some cache or whatever). I haven't tested this, but then that would makes sense that Xcode use "Keychain services", making these underlying .keychain files transparent. So Xcode should just find "automagically" the certificate from an external keychain file.
  2. MobileProvision: ~/Library/MobileDevice/Provisioning Profiles/SOME-UUID.mobileprovision I'm afraid you can't tell Xcode to look to another path.

In both case, I guess you can probably trick the apps (Xcode..)/services(Keychain...) using symlinks... (ln -s ...)

I hope these informations might help you to do the job... Good luck!

Not so off-topic, but I would be curious to know what kind of scenario makes this kind of security legitimate. Once again, only the apple developer admin account has the "god powers"... certificates are pretty much useless w/o that account, unless you are doing ad-hoc/enterprise distribution...

ENDOFEDIT


AFAIK, Apple generates all the certificates = Files.
You can protect these files the way you want, but anyway, to sign an app you will need to copy them on a mac at signing time. (in a particular place, the keychain, where Xcode gets them)
I doubt any "smartcard" or similar solution will be reliable...

What you can do is dedicate one mac to app signing and secure its access (via smartcard, biometrics, just a login/password... or even a locked door!)

Assuming AppStore is your target:

IMHO, being scared of stolen distribution certificates is a bit paranoid and useless.
To submit an app to the AppStore you will need anyway the iTunes account administrator account, the only one that has that power. In other words, a signed package can't be submitted to Apple w/o that account.

So Only that itunes connect admin account/password must really be secured.
(And in worse case I'm pretty sure Apple can block/restitute stolen account)

And with that administrator account, you can cancel any app submission, revoke / regenerate all certificates... (No app is immediatly validated, you have a ~10days approval period to cancel it, with admin notified via email)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文