| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | A crer pelo que li no artigo, posso dizer que compreendo a posição dele. Não se trata de aprovar o DRM mas sim não usar o kernel como forma activa de impedir a sua utilização. O kernel poderia suportar no futuro o hardware TCPA (que tem outras boas utilizações que não DRM), por exemplo.
Penso que ele quer dizer que se alguém quiser usar o kernel do Linux como base para algum equipamento/aplicação que suporte DRM (algum sistema embebido, por exemplo um leitor de DVD) não haverá nada a impedi-lo. Daí até isto querer dizer que vamos ver no futuro um sistema tipo Palladium implementado ou suportado pelo kernel mainstream vai uma enorme distância.
-- Carlos Rodrigues
|
| | | | | | Desde quando é que a TCPA tem boas utilizações? Estás a confundir o chip de criptografia com a plataforma. E mesmo este é mau, porque não é suposto o utilizador ter acesso à chave privada (info do PDF que contém a FAQ oficial). É preciso saber ler as entrelinhas
Desmembrando:
* a intenção é que todos os devices se tornem "ispertos" contendo o chip "Fritz", e deverão utilizá-lo para saber se os dados que passam são legítimos ou não.
== decorre logo que os dados não assinados/verificados por uma chave legítima podem não ser legítimos
* uma bios pode decidir se carrega o sistema operativo se ele estiver assinado.
== e quem controla esta decisão? Quem decide que chave é utilizada para assinar o quê? Esta pergunta é respondida pelo silêncio suspeito dos promotores do TCPA.
* o TCPA está disponível ao mundo do software livre
== mas para quem não o implementar não estará, logo, ou o mundo do software livre abdica da sua liberdade para ter acesso a conteúdos com DRM ou não tem acesso
* dizem que o TCPA não permite a identificação directa dos utilizadores
== logo, permite a identificação por meios indirectos
* a platform user may disable the TPM without the owner's knowledge or permission
== os utilizadores da plataforma não são os donos do hardware, mas sim os utentes do DRM. Logo, se podem desligar, também podem activar ou configurar (não é negado em lado nenhum apesar dos receios) a gosto.
* o TCPA tem um mecanismo de identificação única
== então há um método de fazer identificação individualizada
* Para quem pensa que o "Fritz" chip é como os smart cards...
== a resposta da FAQ é que os smartcards podem ser dissociados da plataforma (mais uma vez, a necessidade de identificação individualizadada).
* application vendors will build applications supporting specific use models
== utilizar o TPM para verificar os conteúdos e definir se podemos ou não utilizá-los de determinada forma (mesmo que tenhamos direito legítimo a essa actividade)
* TC Platform A + Platform owners will determine which OS and applications to run on their platforms
== Os donos da TCPA não são os donos do computador. O computador apenas implementa a TCPA
A enorme distância vai tão longe quanto: os discos não permitirem a instalação de dados não assinados com certas chaves, as bios não permitirem acessos a conexões digitais (video, audio) sem instruções assinadas com certas chaves, etc.. etc... Suportar o TCPA significa também ter de obedecer aos requisitos que forem impostos.
Costuma-se dizer que quem brinca com fogo queima-se. Alegar que o TCPA é uma coisa boa, é o mesmo que alegar que a energia nuclear por fissão é uma coisa boa... o risco supera largamente as vantagens.
|
| | | | Epa, desculpa lá, mas que monte de tretas..
TCPA não tem NADA a ver com software assinado digitalmente.
TCPA (!= Palladium, sobre o qual podemos apenas especular) não te impede de fazer rigorosamenta nada que possas fazer hoje.
TCPA permite-te garantir que uma determinada máquina está a correr um ambiente no qual confias (por alto: um OS que instalaste, configuraste e controlas) e garantir que dados armazenados sob esse ambiente não são acessiveis sob outro ambiente que não apresente a mesma métrica de integridade.
O objectivo é eliminar problemas como a perca ou roubo de hardware contendo informação preciosa.
Contudo, TCPA tem um aspecto que não sendo negro, é cinzento: a possibilidade do o dono do TPM saber as chaves privadas. Neste aspecto, admito que me perdi um bocado a ler as especificações..
Não saber a StorageRootKey é um problema. Principalmente por causa de recuperação de falhas: se o TPM arder, como é que recuperamos os dados se não soubermos a chave? Em qualquer caso, continuo a não ver grandes utilidades para isto em termos de DRM.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | 1. TCPA tem por base conteúdo assinado digitalmente (software, devices e/ou documentos).
2. O hardware TCPA é diferente de um módulo de segurança independente. A diferença é: no primeiro tu és usado, no segundo, tu usas-lo.
3. TCPA não te permite garantir que uma determinada máquina está num ambiente no qual confias. Ou acreditas que a BIOS vai ter espaço para assinaturas sobre todo o ssitema operativo?
4. A confiança que se pretende obter não é a dos utilizadores mas a dos editores de conteúdos
5. Como exactamente é que elimina problemas derivados do roubo de conteúdo sensível? Pensa nisto: filesystem cifrados resolvem esse problema. Mas se te roubarem o PC e tiveres a chave num módulo externo que tu controlas, não conseguem aceder. Com TCPA se te roubarem o PC, levam tudo. Normalmente, e isto especialmente se for um servidor, não é desejável ter o boot impedido por causa de uma prompt.
6. Não sabes nem controlas a StorageRootKey. Isto implica necessáriamente que não estás no controlo das chaves consideradas legítimas. Isto não é cinzento, é preto bréu, e apenas veste o chapeu de inocente ou cúmplice quem acredita/espalha a linguagem bífida estilo newspeak dos apoiantes do TCPA: Microsoft, Intel, RIAA, MPAA, et all...
|
| | | | | TCPA não tem por base conteudo assinado digitalmente.
TCPA por alto:
Num sistema TCPA, o TPM mantém uma métrica de integridade do ambiente de software. Não interessa qual o valor exacto, desde que um dado ambiente dê sempre o mesmo valor e que ambientes diferente (por exemplo, se alguém, instalar outro OS na tua máquina) dêm valores diferente.
O software utiliza o TPM para guardar dados em blobs cifrados e assinados pelas suas chaves, associados à métrica do actual. Os blobs depois podem ser armazenados em qualquer sitio. Para aceder aos dados, o software fornece ao TPM o respectivo blob. Se e só se a métrica do sistema concidir com a métrica armazenada no blob, o TPM devolve os dados decifrados. A utilização de filesystems cifrados requer que um administrador introduza uma chave de modo mais ou menos manual. O que como tu bem disseste, não é algo que queiras, principalmente num servidor. Em TCPA, a chave está no TPM. Não é preciso intervenção humana.
Além disso, não fornece meios de certificação do ambiente de software. Se alguém com acesso fisico alterar o "mount" para guardar a chave do filesystem num local onde possa ter acesso, o sistema vai arrancar sem ninguém dar por ela..
No caso de alguém te roubar um sistema com TCPA, só vão ter acesso aos teus dados através do OS que lá instalaste e dos respectivos controlos de acesso.
Há duas possibilidades de contornar isso:
Análise do TPM para saber as chaves. "Quebrar" as ténicas criptográficas empregues
Deve haver uma meia dúzia de empresas capazes dar uso à primeira opção.. :-D
Não sabes nem controlas a StorageRootKey. Caso não tenha ficado claro: eu não tenho a certeza se a especificação proibe totalmente isso, ou se é possivel exportar a SRK cifrada com a Private EndorsmentKey. No caso desta, também não é possivel extrai-la do TPM, mas pelo menos a especificação prevê a possibilidade de o par de EndorsmentKeys ser gerado por métodos alternativos, que TALVEZ possam ser externos ao TPM.
Como já disse ali em cima:
Não estou a ver grande aplicação de manter a SRK secreta em termos de DRM Ia ser um pesadelo para recuperar dados se houver problemas
Por tudo isso, acho que de uma maneira ou de outra, os TPM vão ter de ter maneira de funcionar com chaves conhecidas.
Outra coisa: que raio entendes por chaves legitimas?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | # Não estou a ver grande aplicação de manter a SRK secreta em termos de DRM
# Ia ser um pesadelo para recuperar dados se houver problemas
Sim, é realmente esse um dos problemas da TCPA. Contudo, é um paraíso para a corrupção ou para um "apagar" retroactivo de documentos ao estilo de 1984 (basta revogar numa CRL a assinatura de um certo documento...)
|
| | | | se ele quiz dizer mesmo isso, presumo que nem o necessitava de dizer, a GPL dá essa liberdade, presumo.
quantic_oscillation
|
| | | | | Uma forma mais isenta de postar essa notícia seria: "Linus não vê como impedir o uso do DRM no kernel". Lógico que para se dar uma notícia, deve recorrer à fontes confiáveis. A minha é o próprio Linus: Ok,
there's no way to do this gracefully, so I won't even try. I'm going to just hunker down for some really impressive extended flaming, and my asbestos underwear is firmly in place, and extremely uncomfortable. I want to make it clear that DRM is perfectly ok with Linux! There, I've said it. I'm out of the closet. So bring it on... I've had some private discussions with various people about this already, and I do realize that a lot of people want to use the kernel in some way to just make DRM go away, at least as far as Linux is concerned. Either by some policy decision or by extending the GPL to just not allow it. In some ways the discussion was very similar to some of the software patent related GPL-NG discussions from a year or so ago: "we don't like it, and we should change the license to make it not work somehow". And like the software patent issue, I also don't necessarily like DRM myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse to play politics with Linux, and I think you can use Linux for whatever you want to - which very much includes things I don't necessarily personally approve of. The GPL requires you to give out sources to the kernel, but it doesn't limit what you can _do_ with the kernel. On the whole, this is just another example of why rms calls me "just an engineer" and thinks I have no ideals. [ Personally, I see it as a virtue - trying to make the world a slightly better place _without_ trying to impose your moral values on other people. You do whatever the h*ll rings your bell, I'm just an engineer who wants to make the best OS possible. ] In short, it's perfectly ok to sign a kernel image - I do it myself indirectly every day through the kernel.org, as kernel.org will sign the tar-balls I upload to make sure people can at least verify that they came that way. Doing the same thing on the binary is no different: signing a binary is a perfectly fine way to show the world that you're the one behind it, and that _you_ trust it. And since I can imaging signing binaries myself, I don't feel that I can disallow anybody else doing so. Another part of the DRM discussion is the fact that signing is only the first step: _acting_ on the fact whether a binary is signed or not (by refusing to load it, for example, or by refusing to give it a secret key) is required too. But since the signature is pointless unless you _use_ it for something, and since the decision how to use the signature is clearly outside of the scope of the kernel itself (and thus not a "derived work" or anything like that), I have to convince myself that not only is it clearly ok to act on the knowledge of whather the kernel is signed or not, it's also outside of the scope of what the GPL talks about, and thus irrelevant to the license. That's the short and sweet of it. I wanted to bring this out in the open, because I know there are people who think that signed binaries are an act of "subversion" (or "perversion") of the GPL, and I wanted to make sure that people don't live under mis-apprehension that it can't be done. I think there are many quite valid reasons to sign (and verify) your kernel images, and while some of the uses of signing are odious, I don't see any sane way to distinguish between "good" signers and "bad" signers. Comments? I'd love to get some real discussion about this, but in the end I'm personally convinced that we have to allow it. Btw, one thing that is clearly _not_ allowed by the GPL is hiding private keys in the binary. You can sign the binary that is a result of the build process, but you can _not_ make a binary that is aware of certain keys without making those keys public - because those keys will obviously have been part of the kernel build itself. So don't get these two things confused - one is an external key that is applied _to_ the kernel (ok, and outside the license), and the other one is embedding a key _into_ the kernel (still ok, but the GPL requires that such a key has to be made available as "source" to the kernel). Linus Também na Slashdot.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | Eu ADORARIA ver o Palladium no kernel Linux. Quanto isto acontecer, finalmente nós poderemos saber realmente o que vem por trás deste negócio. O kernel é GPL. Isto significa que toda e qualquer informação binária dentro dele deve estar disponível em forma de código fonte : inclusive as chaves "secretas", bem como o protocolo de eventuais "informações privadas" que ele enviaria...
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | | Claro, claro. Só que o Linus está a ser um completo bronco (para não querer estar a duvidar da integridade dele). Ora vejamos: 1º confunde DRM com assinaturas digitais. DRM é uma aplicação abusiva de assinaturas. Abusiva porquê? Porque presume para o seu funcionamento correcto a ausência de controlo da chave privada pela parte dos utilizadores. 2º, pelo que li da thread, o Linus esforçou-se por fazer crer que não é capaz de distinguir gpg -b -a linux-2.4.xx.tar.gz e uma bios ser feita de forma a apenas permitir o carregar de um kernel assinado pelo fabricante da BIOS.
Isto é deveras preocupante, pois ou o Linus tem pouca percepção do que é segurança para o utilizador e o que é segurança contra o utilizador (estou a assumir utilizador/dono já agora -- eg. sysadmins), ou então está intencionalmente a querer atirar areia para os olhos de muita gente (pois a Transmeta está a tratar de suportar o DRM como já se soube...).
A ideia de que o cliente tem a opção de não comprar hardware com DRM é irreal. Já ouviram falar em cartel? A pressão para os fabricantes de hardware colocarem DRM nos seus produtos é intensa. O que nos garante que vai existir hardware não drm?
|
| | | | A ideia de que o cliente tem a opção de não comprar hardware com DRM é irreal. Já ouviram falar em cartel? A pressão para os fabricantes de hardware colocarem DRM nos seus produtos é intensa. O que nos garante que vai existir hardware não drm? Se houver procura, haverá oferta.
Acho que a tua aversão ao software não-Livre te fez esquecer uma coisa: a maioria dos consumidores viola sistematicamente as licenças de software proprietário e de conteúdos. E se forem postos perante a opção pagar ou não usar, vai ser não usar. E se tiverem uma alternativa que lhes permita utilizar warez e ripar DVDs, é isso que vão comprar. Fazer uma plataforma que imponha DRM é uma fonte de problemas.. e poucas soluções.
A tua ideia de OS certificados implica uma ruptura completa com os OS anteriores.
Para impedir que as aplicações sejam pirateadas, só se também se exigir que estas sejam certificadas para impedir os cracks habituais. Mas exigir certificação implica uma ruptura com as aplicações antigas e complica o desenvolvimento de software.
Além disso, se alguém pode certificar uma aplicação escrita por si, também pode certificar uma aplicação "cracked" por si.. Outra possibilidade: cifrar os binários de modo a que apenas o OS seja capaz de os ler. O que implica que o OS seja cifrado de modo a que apenas a BIOS seja capaz de o ler. Isto foi tentado com os DVDs e falhou: basear a segurança num segredo partilhado por múltiplas entidades e que não pode ser mudado é má ideia.
Em termos de conteúdos, em teoria até poderia funcionar desde que impedisses a informação de passar por canais que não suportem DRM..
Mas isso também implica deixar de distribuir conteúdos nos actuais formatos que, a bem ou a mal, podem ser lidos em plataformas que não impõem DRM.
Para não falar que o os conteúdos terão forçosamente de passar por um canal que não suporta DRM aṫé chegaram aos sentidos dos seres humanos.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | E se forem postos perante a opção pagar ou não usar, vai ser não usar. E se tiverem uma alternativa que lhes permita utilizar warez e ripar DVDs, é isso que vão comprar. Aqui no Brasil, DVD-Player não "Region Free" ou sem um comando para desligar a trava de regiões não vende.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Existem DVD Players com comandos para desligar o bloqueio de regiões (ie, que não seja uma manha do género mudar um chip)? Também não sabia que era legal vender DVD Players com todas as regiões...
|
| | | | E aqui em Portugal, eu próprio já comprei um NINTAUS (acho que é o 9000, mas não tenho a certeza do modelo) e é REGION FREE!!! Vende-se cá em Portugal!
----
//\anuel /|zevedo |
| | | | | Caro colega, eu diria que por estas bandas não existe DVD Player que não venha de fábrica com pelo menos um código "informal" que misteriosamente desliga o bloqueio de região. Consumidores sustentam a indústria, não leis ou comitês. E lembrando uma máxima do Còdigo Civil: Você pode fazer qualquer coisa, contanto que a Lei não proíba. Pode até ser ilegal vc hackear o aparelho para destravar as regiões (DMCA), mas nunca será ilegal comprar um aparelho que já venha com esta característica.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Eu tenho este, mas por acaso ainda não precisei de o "desbloquear"... :-)
--
antonio soares
Windows has stopped. Press CTRL+ALT+DELETE to restart your computer. |
| | | | Se não calculasse (como calculo) que o departamento dado ao artigo viesse de ignorância sobre o assunto, apeteceria responder que por muito apolíticas que as ferramentas sejam, por vezes os "departamentos" são-no tanto mais quanto se menos se assumem ser.
|
| | | | | | agh, ao contrário: "são-no [apolíticos] tanto menos quanto mais [apolíticos] se assumem ser"
|
| | | | | Ferramentas são apoliticas, mas pessoas não são, portanto não me espantava nada que sete horas depois de aparecer um kernel suportando DRM aparecesse um fork dele sem esse suporte. Ferramentas são apolíticas, mas leis não, portanto será preocupante se o estudo, produção, distribuição ou uso desse fork for ilegalizado. É preocupante pensar se terá mais força a protecção da GPL ou a protecção do DMCA, pois desenha-se uma colisão entre estes dois habitantes do mundo das leis (não sou advogado, mas parece haver uma contradição entre DMCA e liberdade de estudar e modificar código que suporta DRM). O departamento está incompleto... Para a provocação ser total, falta-lhe um ponto de interrogação no fim! (Será por acaso que um "?" tem a forma dum anzol?) No entanto, o facto é que ferramentas são apolíticas. A declaração do facto (atenção: facto!) pode sê-lo ou não, mas a revolta contra a declaração do facto não é, certamente... :^) Desculpa lá o "anzol"... :^) Em todo o caso, esta notícia tem, para mim que não sou apolítico, a imensa virtude de demolir (ou pelo menos erodir) um guru. É minha "política" não gostar de gurus -- ou, para ser mais exacto, não gostar do efeito que eles têm sobre as pessoas que os seguem! Isto porque o facto de alguém dizer ou fazer uma coisa imensamente acertada ou excelente não garante que diga ou faça todas as coisas acertada ou excelentemente.
|
| |
|
